WHATISAI｜実践編

AIを、
あなたの仕事の戦力に変える

仕組みは、もう分かりました。最後は、それを明日からの自分の仕事で効かせる番です。 開発・資料・マネジメント・営業 ── どれも、AIの3つのクセの当てはめ方ひとつで、結果が見違えます。 読み終えるころには「自分の仕事のやり方が変わった」と感じるはずです。

この章は、新しい仕組みを増やしません。これまでの3つのクセ（予測・文脈・ゆらぎ）を、あなたの実務に当てるだけ。だからすぐ使えます。

仕組みを、競争力に「うまくやる」は、3つの原則に集約される

AIを使いこなす人と、振り回される人の差は、才能ではありません。3つのクセから素直に導かれる3つの原則を、意識しているかどうかだけです。

「予測」のクセ だから

事実は、自分が握る

AIは確率で続きを選ぶだけ。事実は保証しない。だから「正しさが命の部分」は人が押さえる。

「文脈」のクセ だから

文脈は、的確に渡す

前提・数字・観点・お手本を渡すと、答えは文脈に沿う。ただし“多いほど良い”ではない（後半の落とし穴参照）。

「ゆらぎ」のクセ だから

ぶれ幅は、仕事に合わせる

確実さがほしい仕事は堅く、発想がほしい仕事は広く。同じAIを、目的で使い分ける。

まず、見てください同じAIで、出力はここまで変わる

3つの原則を当てるだけで、実際の出力がどう変わるか。変えたのは「指示の仕方」だけ──同じAIです。本物の例で見てください。

見て確かめる：同じAI・同じ仕事で、出力はここまで変わる例を切り替えてください。変えたのは「指示の仕方」だけ。実際の出力の差を見てください。
before：雑な指示
来期の戦略をまとめて
1. 売上拡大　2. コスト最適化　3. DX推進　4. 人材強化 ── どの会社にも当てはまる総花的な4項目。自社の数字も、決めるべき論点も無い。
after：クセを踏まえた指示
来期の取締役会用。前提＝当社はSaaS、ARR12億・成長率が+8%に鈍化、主因は中小の解約。論点は「成長再加速の打ち手の優先順位」。私見では「エンタープライズ特化」。役員向けに3スライド構成、各スライド要点3つ、反対意見も1枚。
スライド1 現状：ARR+8%鈍化の主因は中小解約率18%／スライド2 提言：エンプラ特化（単価4倍・解約半減の根拠）／スライド3 反論と対策：初期コスト増→既存資産で吸収。── そのまま叩き台に使える。

変化：一般論 → 自社の意思決定に使える叩き台

賢いモデルに変えたわけでも、特別な呪文でもありません。クセを踏まえて指示しただけで、ここまで変わる。これが「自分の仕事が変わる」の正体です。

次に、地図を持つその仕事、自分でやる? 任せて見抜く?

すべてを自分でやる必要も、丸投げする必要もありません。2つの問いで、任せ方はほぼ決まります ──「事実の正確さが致命的か?」と「多様な発想がほしいか?」。

タテ＝事実の正確さが致命的か　／　ヨコ＝多様な発想がほしいか

言葉で覚えるより、自分の仕事で当ててみるのが早い。下で試してください。

あなたの仕事で、試す：任せ方診断あなたが抱えていそうな業務をタップしてください。3つのクセが「なぜ難しいか」と「うまくやる処方」を返します。

↑ どれか一つ、選んでみてください

深掘り｜開発Claude Code の“本物の”使い方

「AIにコードを書かせる」と聞くと、SNSで流れる華やかなデモを思い浮かべるかもしれません。けれど現場で本当に成果を出しているのは、もっと地味で強力な型です。共通点は「推測させない」こと ── すべて“予測”と“文脈”のクセで説明できます。

① コードベースを探索してから書く

Claude Code は、いきなり書かず自分で関連ファイルを探索してから着手します（あなたは「どこを見て」と方向づけるだけ）。なぜ効くか：既存コードという事実が文脈に入り、的外れな生成が激減する（“予測”のクセの弱点を“文脈”で塞ぐ）。

② テスト駆動の反復ループ

書く→テスト実行→失敗を見て直す、を自分で回させる。なぜ効くか：実行結果が文脈に戻り、次の予測が現実に矯正される。“推測”が“検証”に変わる ── これがエージェントの正体です。

③ 計画してから実行（plan mode）

段取りを先に立てさせ、合意してから実装させる。なぜ効くか：考えを書き出すと文脈が整い、確からしさが上がる（推論モデルと同じ理屈）。大きな改修ほど効く。

④ ルールを書いた「CLAUDE.md」を置く

規約・技術選定・禁止事項を1ファイルに。なぜ効くか：毎回それが文脈に入り、指示が揃う。ただし盛りすぎ厳禁（落とし穴①へ）。

とくに②が肝心です。なぜ「テスト駆動」だと信頼できるのか ── 動かして確かめてください。

動かして確かめる：推測を「検証」に変えるループ素のチャットは記憶だけで“推測”します。エージェントは自分で現実を取りに行く。1歩ずつ進めて、確からしさが上がるのを見てください。
① 関連ファイルを読む
② 方針を立てて書く
③ テストを実行する
④ 失敗を見て直す
文脈（いま分かっていること）

まだ何も確かめていない ── 素のチャットは、この状態で“推測”して答える。

答えの確からしさ（接地度）
28%

経営インパクト：内製の現実味が変わります。「作れるか/作れないか」ではなく、「どこまで任せ、どこを人が握るか」の設計問題になる。その判断軸が、まさにこの資料の3つのクセです。

さらに上の型｜開発を超えて効くスキルとサブエージェントで、AIを“専門家チーム”にする

ここまでは「1人のAIに上手に頼む」話でした。もう一段上の型が、サブエージェントとスキルです。派手さはないけれど、組織で効く ── そして両者の本質は同じ、コンテキスト（文脈）の設計です。だから、ここまでの話の延長線上にあります。

サブエージェント

分担して、文脈を汚さない

何か：大きな仕事を独立した小タスクに分け、別々のAIに並行で任せる仕組み（調査・実装・レビューを分担）。

なぜ効くか：1つの会話に全部を詰めると文脈が膨れ、肝心な点が薄れる（“文脈”のクセの裏面＝中盤の見落とし）。サブエージェントは各自が自分の文脈だけを持つので混線せず、しかも並行で速い。

実用：独立した複数調査を並列で回す／「実装役」と「レビュー役」を分ける（作る人・検（あらた）める人）。注意：連携の手間があるので、単純な仕事はむしろ1人の方が速い。

スキル

専門ノウハウをパッケージし、必要な時だけ渡す

何か：特定タスクの手順・規約・ノウハウを1つの「スキル」にまとめておき、AIが必要な時だけ読み込む（progressive disclosure＝段階的開示）。

なぜ効くか：何でもかんでも常時の指示書（CLAUDE.md）に積むと文脈が肥大する（落とし穴①）。スキルは該当タスクの時だけその知識を文脈に載せるので、軽さと専門性を両立できる。

実用：自社のレポート様式・コードレビュー基準・ブランドガイドラインを「スキル」化 → 誰が使っても同じ品質で再現。経営インパクト：属人的なノウハウを“組織のスキル”として資産化できる。

ひとことで
スキル＝入れる知識を絞って常設の質を上げる。サブエージェント＝文脈を分けて混線を防ぐ。どちらも「何を文脈に入れ、何を入れないか」という設計 ── 落とし穴①「文脈は多いほど良いではない」への、最も強力な答えです。属人芸を“組織の仕組み”に変える、経営者向けの一手でもあります。

転ばぬ先に鵜呑みにすると危ない、5つの落とし穴

ここまでの助言も、そのまま鵜呑みにすると逆効果になる落とし穴があります。先回りで潰しておきましょう。どれも、3つのクセで理由が説明できます。

① 「文脈は多いほど良い」ではない（最重要）CLAUDE.md や資料を盛りすぎると、肝心の指示が埋もれて精度が落ちる。これは“文脈”のクセの裏面 ── 長い文脈は中盤が読み飛ばされる（"lost in the middle"）。対処：的確に・簡潔に。要らない物は入れない。CLAUDE.md は「効く一軍」だけに絞る。
② 事実確認まで任せる確率予測に事実は保証できない（“予測”のクセ）。→ 数字・固有名詞は必ず人が照合。
③ 任せきりで“検証”を省くエージェントの強みは「現実で確かめる」こと。テストや確認を省けば、ただの推測に逆戻り。→ 受け入れ確認は人が持つ。
④ 機密をそのまま貼る仕組みは学習しないが、ログの扱いは別問題（第4章）。→ 利用プラン・設定を確認。
⑤ ぶれNGの仕事で発想モード多様性が誤差になる（“ゆらぎ”のクセ）。→ 事実作業は確実性重視（temperatureを下げる）。
まず予想してみる

「議事録を5分で要約させたら、言ってない決定事項が混ざった」。最初に打つべき手は？

発展発展：エージェントが“推測”を“検証”に変える仕組み（Claude Code の理論）▼ 数式が苦手な方は飛ばしてOK

Claude Code のようなコーディング・エージェントが、なぜ素のチャットより信頼できるのか。鍵は「文脈を、自分で取りに行く」点にあります。

① 接地（grounding）：ファイルを読む・コマンドを実行するたび、その結果が文脈に追加されます。素のモデルは記憶から確率を出すだけ（“予測”のクセ）ですが、エージェントは現実を文脈に入れてから確率を出す（“文脈”のクセ）。これが「推測→検証」の転換です。

② 反復ループ：観察→思考→行動→観察…を回すたびに、文脈が事実で豊かになり、次の予測が現実に矯正されていく（上の図そのもの）。

③ コンテキスト・エンジニアリング：何を文脈に入れ、何を入れないか（CLAUDE.md を絞る・探索範囲を限る・サブエージェントで分離する）が成否を分ける新しい設計分野です。プロンプト“術”から、文脈“設計”へ。落とし穴①は、この設計の失敗例です。

⚠ 注記：エージェントも万能ではありません。文脈ウィンドウの上限、長時間タスクでの文脈管理、ツール誤用やプロンプトインジェクションのリスクが残ります。だからこそ「重要操作は人の確認」が標準です。

この章のひとこと

AIを戦力にする鍵は、才能ではなく
「事実は握る・文脈は的確に・ぶれは合わせる」。

── 明日、いちばん時間を使っている仕事を一つ選んで、この3原則を当ててみてください。やり方が変わるのを、その手で感じられるはずです。