社員全員がClaude Codeを使う状態を標準にしたい、と考えている。
エンジニアだけでなく、経理も総務も企画も、日々の定型作業をClaude Codeに任せるのが当たり前になる組織を作りたい。 数年後にはClaude Code自体が別の道具に置き換わっているかもしれないが、それでもこの標準化には賭ける価値があると思っている。
ツールではなく働き方に賭ける
賭けの対象を勘違いすると、この投資はすぐに無駄になる。
Claude Codeという製品名を社員に覚えさせても、製品が入れ替わった瞬間にその知識は失効する。 標準化すべきなのは製品名ではなく、その製品が要求する働き方の方だ。
具体的には四つある。
- 依頼を言語化する力：あいまいな指示ではAIエージェントは正しく動かない。何を、どの範囲で、どう確認してほしいかを文章にする訓練が必要になる。
- 小さく刻んで検証するループ：一度に大きな成果物を作らせて後からまとめて確認するのではなく、小さい単位で作らせて都度確認する進め方に慣れる必要がある。
- 出力を検算する習慣：AIエージェントは自信満々に間違うことがある。任せた側が最終責任を持って確かめる姿勢を、最初から前提として持たせる。
- 文脈を資産化する発想：業務の背景やルールを口頭伝承にせず、次にAIエージェントへ渡せる形の文書として残しておく。このサイトのCLAUDE.mdはその実践そのものだ。
この四つは、Claude Codeが別のツールに置き換わっても社員個人のポータブルスキルとして残る。 標準化の投資対象をここに置けば、ツールの寿命に関係なく回収できる。
禁止では止まらないシャドーAI
社員が個人のブラウザでAIを使い始めるのは、公式なやり方が用意されていないからだ。
会社が使えるツールを用意せず「AIの利用は慎重に」とだけ通達すると、現場は隠れて使う方を選ぶ。 承認が遅い、使い勝手が悪い、そもそも会社支給のツールがない、という状況では、社員個人のアカウントでの利用が一番速い解決策になってしまう。
Claude Codeを標準にするという方針は、この構図に対する回答でもある。
会社として正式に使ってよいツールを用意し、そこにデータの扱い方や承認の速さを整えておけば、社員が個人アカウントに逃げる理由がなくなる。 標準化は業務効率化の施策であると同時に、シャドーAI対策そのものになる。
デフォルト化を支える条件
方針を掲げるだけでは定着しない。
非エンジニアの入り口を短くする。 ターミナルやコマンドという言葉だけで及び腰になる社員は多い。 最初の成功体験を「使い慣れたExcelやCSVの定型作業を任せてみる」ところに置き、コマンドを覚える負担を最小限にしたオンボーディングを用意する。
承認フローを利用の速さに合わせる。 新しいツールの利用申請に数週間かかる稟議を通す設計では、社員は待ちきれずに個人アカウントへ戻る。 リスクの低い用途から即日で使える簡易審査ルートを別に用意しておく。
成果の測り方を先に決める。 市場価値の最大化という目的を掲げるなら、何をもって効果とするかを先に決めておく必要がある。 削減できた作業時間なのか、社員がAIエージェントに任せる範囲の広がりなのか、指標を曖昧にしたまま標準化を進めると、施策は号令だけで終わる。
リスク管理を先に済ませておく
標準化を進めるほど、AIエージェントに渡すデータの範囲は広がる。
顧客の個人情報や社内の未公開情報をそのまま渡してよいかどうかは、標準化を始める前に決めておく事項であって、後から整理する事項ではない。 クライアントから預かった表形式データを扱う場面については、client-privacy-guardスキルの話で書いた通り、渡す前にマスキングする工程を挟む設計が要る。
権限の絞り方や運用面の注意点は、Claude Codeのセキュリティ運用にまとめてある。
標準化の号令とリスク管理の設計は同時に進める必要があり、片方が先行するともう片方の不備が事故として表面化する。
中期的に賭けている理由
自分が大学職員として日々の集計作業をClaude Codeに任せてきた経験から言えるのは、覚えたのはコマンドではなく依頼の書き方だったということだ。
ツールの名前は数年後に変わっているかもしれない。 それでも依頼を言語化する力、小さく検証する習慣、出力を検算する姿勢は、次のツールに乗り換えた瞬間にそのまま持ち込める。 非エンジニア社員の標準スキルとしてここに投資する判断は、ツール選定ではなく人材育成の判断であり、だからこそ中期的な市場価値につながると考えている。