§この章のねらい
コーチングをやっていて、一番挫折者が出るのが「セットアップは終わって、CLAUDE.mdも書いた。さあ触ってみよう」となった直後の1〜2週間です。ここで9割の経営者は詰まります。詰まり方はほぼ決まっていて、「AIに何かをやらせようとしたら、途中で止まった」「エラーが出て意味がわからない」「動いたと言っているのに、実際にファイルを開いたら何もない」——このどれかです。
面白いのは、詰まっている経営者に「なぜ詰まっているのか」を聞くと、たいてい「AIとの対話の作法」を教わっていないだけだということです。プロンプト技法の本を読んだり、YouTubeでプロンプトエンジニアリングの動画を見たりしている人ほど、この初動でつまづきます。理由は単純で、いま経営者がやっているのは「賢いプロンプトを書くこと」ではなく、「AIとどう組んで仕事を進めるか」という運用習慣の話だからです。
この章では、プロンプト技法よりも先に身につけてほしい5つの作法を扱います。「AIに聞く文化を自分の中にインストールする」「詰まった時の脱出3手」「モデル選択」「AI出力を鵜呑みにしない実機Verify」「MCPとCLIの使い分け」。
どれもコーチング現場で毎週のように出てくる話で、これを腹落ちさせるだけで、経営者はひとりで走れるようになります。逆に言うと、これを飛ばしてプロンプト技法に走ると、いつまでも「AIに詳しい部下」を求め続けることになります。
§3-1. まず「AIに聞く」を自分にインストールする
だから作法として「まずAIに聞く」を先に入れます。
§解説
Claude CodeやCodex(GPT-5.6系のCLI)を導入した経営者に、最初にお願いしていることがあります。「1週間、判断に迷ったら全部AIに聞いてください」というものです。プロンプト技法を教える前、CLAUDE.mdの詳しい書き方を教える前に、これが先です。
なぜかというと、非エンジニアの経営者ほど「AIに聞くべきかどうか」を人間側で判断してしまうからです。「これはAIじゃ無理だろう」「こういう業務系はまだ早いだろう」——この線引きを人間がやると、9割は間違います。AIの進化速度が異常だからです。Claude系のモデルは月に十数回アップデートが入ります。先月「これは無理」だった処理が、今月には普通にできるようになる。この頻度で線引きを更新できる人間はいません。
エラーが出たらそのエラー文をコピペしてAIに投げる。仕様がわからなかったら「これって何?」と聞く。他社事例を集めたければ「業界内でこういう事例ある?」と聞く。作業を始める前に「どういう順序でやるべき?」と聞く。人間の頭の中で悩む時間を、全部AIに丸投げする側に切り替えます。
もうひとつ強調しているのが、「1つのAIの答えを信じきらない」という作法です。Claude、GPT、Gemini、Grok——どれも得意分野が違います。特に判断系のタスクでは、複数AIに同じ問いを投げて、答えの中央値を取る。これを常用テクニックにしてください。3つ聞いて2つが同じことを言っていたら、そっちが正しい可能性が高い。逆に3つとも違うことを言っていたら、その問いは人間側の設計が悪いです。
この作法が入ると、経営者自身がAIをどこまで使えるかを実感で理解できるようになります。そうなって初めて、「じゃあこの業務は社員にAI化してもらおう」という判断ができる。順序が逆——社員に丸投げして経営者は触らない——だと、AI化プロジェクトはほぼ確実に失敗します。
§実装を頼む前に「計画」させる（プランモード）
いきなり「作って」と頼むより、「調べる → 計画する → 承認して実装 → 確認」の順で頼むと成果物の質が上がります。現在のClaude Codeにはこの型を仕組みにした「プランモード」という公式機能があり、オンにするとClaudeはファイルを読んで調査はしますが、あなたが計画を承認するまで編集が実際にブロックされます。「お願いだから書かないで」ではなく、仕組みで止まるのが利点です。
- デスクトップアプリでは、送信ボタンの横のモードセレクタで「Plan」を選びます。プロンプト欄に「/plan やりたいこと」と打っても入れます
- 計画を承認すると、自動的に実装へ移ります
- AIが出してきた計画・TODOリストは「監視対象」です。変な項目が混じっていたら、承認せずに「この項目は不要、方向はこう」と直してから進めてください
- 一文で説明できる小さな修正（誤字直し・1行の変更など）には、プランモードは手間のほうが大きいので不要です
§3-2. 詰まった時の脱出3手
この詰まりを解消する3手セットを、コーチングでは全員に叩き込みます。
§解説
コーチング現場で一番よく起きるのが、「途中で詰まって、そのまま数時間潰す」という事故です。特に多いのが動画字幕生成やスクレイピング系のタスクで、AIが同じエラーをループする、あるいは黙り込むパターン。ここで「今日はもうやめよう」と離脱してしまうと、その週の学習がゼロになります。
1手目: 「エンジニアじゃない人間にわかりやすく解説して」と指示する
エラーメッセージや動作を、AIに一度解説させます。目的は「工程を理解する」ことです。何がどう動いていて、どこで止まっているのか、非エンジニア向けの言葉で説明させる。これをやるだけで、「あ、この途中の処理いらないな」「順序が逆じゃない?」といった気づきが出ます。多くの場合、AIに解説させている過程で、AI自身が原因に気づいて修正案を出してきます。
2手目: 中間出力をテキストファイルで確認する
AIに何かを投げる前に、「その中身をテキストファイルに書き出してから、次の処理に渡して」と指示します。字幕生成なら、動画から抽出した文字起こしを一度.txtに出す。データ集計なら、集計前の生データを.csvに出す。中間結果を目で見て確認するステップを、パイプラインに必ず1つ挟みます。詰まりの半分以上は「AIに渡していたデータが、そもそも壊れていた」ケースです。
3手目: 「自己レビューを繰り返しながら誤修してくれ」と指示する
AIが動かないコードを書いたとき、そのコードを別チャットに投げて「これのバグを指摘して」と言う。あるいは同じチャット内で「今書いたコードを自分でレビューして、問題点を挙げて修正して」と指示する。1回で直らなければ「もう1回自己レビューして」を繰り返す。これは「ループ回して品質を上げる」という考え方の入り口で、詳しくは第4章のループエンジニアリングで扱います。
そしてもうひとつ、非エンジニアの方に絶対覚えてほしいのがエラー画面のスクショをそのままAIに投げるという作法です。WindowsならWin + Shift + S、MacならCmd + Shift + 4。範囲選択でクリップボードにコピーして、Claude Codeやチャットの入力欄にペースト。
これだけで、9割のエラーは解消します。「スクショそのまま送って解決する」という発想が、まっとうな社会人の頭からはまず出てきません。だから作法として最初に叩き込みます。
詰まる=Claude Codeが悪い、ではなく、詰まる=まだ使い方が足りていない、と捉えてください。この認識だけで、コーチング卒業後の独学速度が変わります。
§3-3. モデル選択と使い分け
結論から言うと、事業で使っているなら最新の安定版を最上位で使ってください。
§解説
Claude Codeを起動すると、モデル選択という項目があります。Opus 5 / Sonnet 5 / Haiku 4.5(2026年8月時点)といった名前が並びます。ここを何となく「新しい方がいいだろう」で選ぶと、しばらく地獄を見ます。
(この節に出てくる具体的なモデル名・バージョン名は、入れ替わりが速いため節末の「ツールの現在地」にまとめてあります)
コスト削減のためにSonnetやHaikuに落とすのは、経営者がやることではありません。Claude Codeを事業運営に使っているなら、月数万円のAI料金は判断の質を上げるための必要経費です。1件の意思決定が数百万〜数千万に効いてくる立場の人が、月数万を惜しんでモデルを下げるのは合理性がありません。詳しい料金プランは第0章の料金表を参照してください。
一方で、注意点も明確にあります。新しすぎるモデルは、しばらく触らない。例えば大型バージョンアップ直後のモデルは、世界中で不具合報告が上がることがよくあります。
ツール呼び出しが失敗する、関係ない話を始める、別プロジェクトのファイルを勝手に読みに行く、Wi-Fiを切ってくださいというセキュリティ警告を誤発火する——このあたりは実際にコーチング現場で観測してきた症状です。こういう時は、/modelコマンドで一つ前の安定版に下げる、あるいはCodex側(GPT-5.6系のCLI)に切り替えて避けます。
軽量モデル(2026年8月時点ならHaiku 4.5)を使うのは、定型業務に絞ってください。毎朝の日報配信、決まったフォーマットでの通知、単純な整形処理。ここは高速・安価なモデルで十分ですし、待たされないメリットの方が大きい。逆に、判断が絡むタスク、設計が絡むタスク、複雑なデバッグは絶対に最上位モデルです。ここで削ると、時間もお金も余分にかかります。
もうひとつのポイントは、シンキング(思考)モードは常にHighに固定することです。モデルによっては思考の深さを調整できますが、経営タスクで浅い思考にする理由はありません。数秒〜数十秒の思考時間を惜しむより、その先の意思決定の質を上げる方が桁違いにリターンがあります。
Codex(GPT-5.6系)を持っている場合は、真面目な作業はCodex、柔軟な提案はClaude Codeという使い分けが世界標準になりつつあります(2026年8月時点)。両方立ち上げて、同じ問いを投げて、答えを比べる。この2枚使いが、いま経営者のワークスタイルとして最強です。
§3-4. AI出力を鵜呑みにしない——実機Verify必須
だから作法として、AIの完了報告を鵜呑みにせず、必ず自分の目で実機を確かめるを叩き込んでください。
§解説
Claude Codeは確率のツールです。1回の応答で99%正しくても、1万回動かせば単純計算で100回誤ります。しかも困ったことに、AIは自信満々に間違えます。存在しない関数を「あります」と言い、書いていないファイルを「作成しました」と言い、動いていない処理を「動きました」と報告する。これはClaude Codeに限らず、あらゆるLLMに共通する構造的な問題です。
「作成しました」と言われたら、そのファイルを実際に開く。「動きました」と言われたら、実際にブラウザやアプリで起動してみる。「データを取り込みました」と言われたら、実際にそのデータベースやObsidianを開いて中身を見る。これをやるかやらないかで、事業レベルの品質差が出ます。
もう一段強力な仕組みが、AI出力を別のAIで自動チェックするというやり方です。Claude Codeで生成したコードを、Codexに投げて「バグを指摘して」と言う。Claude Codeで作った要約を、GPTに投げて「事実誤認がないか検証して」と言う。
パイプライン化するなら、生成→テキスト化→別AIでレビュー→差分修正、という基本形をどの業務にも組み込みます。1回のAI応答ではなく、複数AIを直列させて品質を担保する。この考え方は第4章のマルチAI議論・ループエンジニアリングでもっと深く扱いますが、ここでは「1回で信じるな」だけ覚えてください。
また、AIに最新情報を扱わせるときの作法として、Web検索を明示的に指示する、あるいはContext7 MCPのようなドキュメント参照MCPで最新情報を引き込むことも必須です。AIの学習データは常に数か月〜1年古い。ライブラリの仕様やSaaSの仕様が変わっている前提で、必ず最新情報の参照経路を確保してください。
そして、テストコード。非エンジニア経営者にはハードルが高く聞こえますが、Claude Codeに「このスクリプトのテストコードも一緒に書いて」と言うだけで自動生成されます。テストコードは、AIが「動いた」と言った内容を人間側で機械的に検証するための保険です。事業運営で使うなら必ず入れてください。
§3-5. MCPとCLIの使い分け——CLI優先が鉄則
鉄則: CLIがあるならCLIを使え。
§解説
Claude Codeを使い込むと、外部サービスとの連携方法として大きく2つが出てきます。MCP(Model Context Protocol)とCLI(コマンドラインツール)です。この使い分けを間違えると、Macが重くなったり、意図しないメモリ消費で作業が止まったりします。
わかりやすい例えでいうと、MCPは「部屋」で、CLIは「どこでもドア」です。
MCPはグローバル設定またはディレクトリ別設定でClaude Codeに常時接続されます。使っていない時もメモリを占有します。部屋を作るのと同じで、便利ではあるけれど、常にそこに構造がある。数が増えると重くなる。特にNotion MCPやSlack MCPのような常時接続系は、10個・20個入れるとClaude Code自体がもっさりします。
一方CLIは、必要な時だけコマンドで呼び出す仕組みです。使い終わったら終了する。メモリを占有しない。どこでもドアと同じで、行きたいときに開いて、用が済んだら閉じる。
鉄則: CLIがあるならCLIを使え。Slackのファイルアップロードも、GmailやCalendarも、Google WorkspaceもCLI(gogcli等)があります。MCPで同じことができるとしても、まずCLI版がないかを確認してください。CLIがなければMCPを使う、という順序で判断します。
Web連携も同じ考え方です。優先順位は、API > CLI > Playwrightの順です。公式APIが提供されているサービスは、まずAPIで叩く。APIがなければ、CLIツールが公開されていないか探す。CLIもないSaaSのときだけ、最後の手段としてPlaywright CLIでブラウザ自動化する。この順序を守ると、事故率が桁違いに下がります。
補足として、Playwright CLIは非常に強力です。ログインが必要なSaaSの情報でも、--load-storageで認証済みセッションを保存しておけば、Claude Codeから自動でログインして画面キャプチャや情報抽出ができます。「公式APIがない」「CLIもない」状況でも、Playwrightがあれば大抵の情報は取れます。ただし、これは重い処理なので、他の手段がある場合はそちらを優先してください。