こんにちは、株式会社K.Platinum代表の沼田です。
「AIエージェントを導入したのに、思ったほど開発が速くならない」——もしそう感じているなら、原因はツールではなく"依頼の出し方"かもしれません。
少し前に書いた「Claude Code・Cursor・Devin。AIエージェント3つを実務で使い分けている話」の続編です。あの記事では「どのツールをどの場面で使うか」という話を書きましたが、今日はその先の話——「ツールが揃っても、人間側がうまく依頼できないと結局スピードが出ない」という話を書きます。
僕は半年、社内のAIエージェント運用を観察してきて、ひとつの結論にたどり着いています。
AIエージェントの実務運用で最初に詰まるのは、「コードを書かせる」フェーズではなく、その前の「ブリーフィングする」フェーズ。
今日はこの「ブリーフィング」というスキルの中身を、社内で標準化したテンプレと併せて書きます。
"AIに書かせる"の速さに、社内で温度差が出始めた話
きっかけは、社内の温度差でした。
「AIに書かせると速いよね」と楽しそうに話す社員がいる一方で、別のチームでは「AIに振り回されている」「修正の方が時間かかる」という声が同時に上がっていました。
最初は「個人のスキル差かな」と思いました。でも、よく観察してみると、スキルの問題ではなかった。
速いと感じている人と、遅いと感じている人で、AIへの"依頼の出し方"がまるで違う——これに気づいたのが昨年末です。
速い人は、AIに「依頼書」を渡している。遅い人は、AIに「ふわっとした要望」を投げている。
そして決定的なのは、速い人自身も「自分が何を渡しているか」をうまく言語化できていなかったことです。「なんとなくこういう書き方をすると、AIがちゃんと動く」という暗黙知のレベルで止まっていた。
これを言語化しないと、組織で再現できない。それで僕は半年かけて、社内で「AIブリーフィング」というスキルを定義しなおすことにしました。
AIエージェントは「コードを書くマシン」ではなく「依頼を受けるマシン」だった
ここで一旦、認識のフレームを書いておきます。
僕が初心者だった頃、AIエージェントを「コードを書くマシン」だと思っていました。プロンプトを投げる → コードが出てくる、というモデル。
でも実務で使い込んでいくと、AIエージェントは「コードを書くマシン」というより、「依頼を受ける同僚」のように振る舞います。
- 目的が曖昧だと、勝手に解釈する
- 前提条件を知らないと、教科書的なコードを書いてくる
- 制約を伝えないと、見当違いの方向に突っ走る
- 期待アウトプットを言わないと、過剰にも過小にもなる
- 検収基準が無いと、テストもドキュメントもつかない
つまり、人間の同僚に仕事を頼むときとほぼ同じ依頼スキルが要る。違うのは、AIは口頭の補足や雑談を理解せず、文字で渡したものだけが入力になる、という点です。
「コードを書く」は依頼を受けたあとの結果でしかない。本体は依頼を組み立てる側にある——というのが、半年たどり着いた認識フレームです。
ブリーフィングの中身 — 5つの構成要素
社内で議論を重ねて、「これを書けばだいたいAIが暴走しない」という5要素に落とし込みました。広告業界の「クリエイティブブリーフィング」をそのままエンジニアリングに持ってきたイメージです。
1. 目的（Goal）
「なぜこのコードが必要か」のビジネス・運用文脈。AIに「上位概念」を渡しておくと、判断に迷ったときに自走できる。
2. 前提（Context）
「このコードはどこに置かれるか」「既存システムの構造」「使うフレームワーク・ライブラリのバージョン」「ドメイン用語」。前提が抜けると、AIは"教科書的に正しいが、このプロジェクトでは間違っている"コードを書く。
3. 制約（Constraints）
「やってはいけないこと」「依存させてはいけないライブラリ」「触ってはいけないファイル」「パフォーマンス制約」「セキュリティ要件」。ネガティブな指示を明示するのが想像以上に効く。
4. 期待アウトプット（Output）
「成果物の粒度（関数1つ / モジュール1つ / PR丸ごと）」「コードの言語・ファイル構成」「コメント・型定義の有無」「README・テストコードの有無」。
5. 検収基準（Definition of Done）
「どうなったら完了か」を1〜3行で。「Aの引数で呼んだらBが返ること」「既存テストがすべて通ること」「コード行数が100行以下に収まること」など、テスト可能な形で書く。
この5要素を意識して書いた依頼は、AIエージェントから返ってくる成果物の質が、体感で2〜3倍変わります。
なぜ「ブリーフィングが下手な人」は、AIに振り回されるのか
「ブリーフィング上手」と「ブリーフィング下手」の差は何か。半年観察した結果、ひとつの仮説に行き着きました。
コードレビューの解像度が低い人ほど、AIブリーフィングも下手
これは結構強い相関でした。
考えてみれば当たり前で、コードレビューの解像度が高い人は、
- 「この変更で他のどこに影響が出るか」がイメージできる → 制約条件を書ける
- 「この設計だとここが破綻するな」と先回りできる → 前提を書ける
- 「このPRが完了したと言える条件は何か」を持っている → 検収基準を書ける
つまり、AIブリーフィングのスキルは、シニアエンジニアが持っている"設計力・レビュー力"の言語化版だったんです。
逆に言うと、ジュニアがAI使ってもなかなか速くならない理由はここにあります。「コードを書く速度」はAIが補完しても、「設計・レビュー側の解像度」を持っていないと、依頼自体がふわっとして、結果も妥当性チェックもできない。
ジュニアにAIを渡しても自走力が上がらないチームがあるなら、それはツールの問題ではなく設計・レビュー力の育成不足だと思います。
17人ITコンサルで運用した「ブリーフィング標準」3つのテンプレ
うちの17人組織で運用しているテンプレを、簡略化して公開します。社内のNotionに貼ってあるやつのエッセンスです。
テンプレA: 機能追加ブリーフ（既存コードベースに機能を足すとき）
## Goal
（このコードが解決するビジネス・運用課題を1〜3行で）
## Context
- リポジトリ: （URL or 説明）
- 既存の関連モジュール: （ファイルパス）
- 使用言語/FW: （バージョン込み）
- ドメイン用語: （プロジェクト固有の用語を箇条書き）
## Constraints
- やってはいけないこと:
- 触ってはいけないファイル:
- 依存に追加してはいけないライブラリ:
## Output
- 成果物粒度: （関数1個 / モジュール1個 / PR一式）
- 必要なテストコード: （あり / なし / E2Eのみ）
- 必要なドキュメント: （あり / なし）
## Definition of Done
- （テスト可能な完了条件を1〜3行で）
テンプレB: バグ修正ブリーフ（既存挙動を直すとき）
## Goal
（直したい挙動を1行で）
## Reproduction
（再現手順 / 失敗ログ）
## Hypothesis
（原因仮説。なければ「不明」と書く）
## Constraints
- 既存の◯◯機能を壊さないこと
- 既存テストが全て通ること
## Output
- 修正パッチ + 失敗を再現するテストケース
## Definition of Done
- 失敗ケースが通る + 既存テストが緑
テンプレC: 探索ブリーフ（実装方針を相談したいとき）
## Goal
（何をやりたいか）
## Context
（既存制約 / 候補技術）
## Output
- 実装方針案を3つ、メリット・デメリット・推奨つきで提示してほしい
- 全部の実装はしないこと
「全部の実装はしないこと」——これが地味に大事です。書かないと、Devin系はゴリゴリ実装まで進めてしまうので、調査だけ頼みたい時は明示します。
社内では、PR起票のとき・難しめのIssueを切るときは、これらのテンプレをコピペで埋めることをルール化しました。手間に見えますが、AIが書き始めるまでの「依頼書整備時間」がチームで揃うので、結果的に手戻りが減っています。
ちなみに、ここまでのテンプレは自由に使ってもらって構いません。実際にご相談いただくのは「テンプレは配れたが、組織として定着しない」という一歩先の段階が多いです。
ブリーフィング力を組織で育てる3つの仕掛け
最後に、組織でブリーフィング力を育てるためにやっている3つを書きます。
仕掛け1: 「他人のブリーフ」を週1で見せ合う
各エンジニアが書いたAIへの依頼書を、週1で1人1本シェアします。コードレビューならぬ「ブリーフレビュー」。「制約が薄い」「目的が抽象的すぎる」と相互フィードバックします。
これがブリーフィング力を最速で上げる仕掛けだと、半年運用してみてはっきりしました。コードレビューが設計力を育てるように、ブリーフレビューはブリーフィング力を育てる。
仕掛け2: 過去ブリーフをリポジトリに残す
良いブリーフは資産です。「過去にやった類似タスクのブリーフを探す → 流用する」が、新規ブリーフを書くより圧倒的に速い。
うちでは社内リポジトリに briefs/ ディレクトリを作って、PRと紐づける形で残しています。
仕掛け3: AIの「失敗した出力」を残す
意外と効くのが、AIが失敗したケースのアーカイブです。「この書き方で投げたら、こんな見当外れが返ってきた」というBefore/Afterを社内に残す。
失敗事例を見ると「あ、目的を渡さなかったから的外れになったのか」と、ブリーフィングの欠落要素が逆算で見えます。成功事例より失敗事例の方が、学びが速い。
まとめ — AIに置き換わるのは「コードを書く時間」、置き換わらないのは「人に伝える解像度」
長くなりましたが、まとめると一つだけ。
AIエージェント時代に置き換わるのはコーディングの時間で、置き換わらないのは「同僚（≒AI）に解像度高く依頼する力」。
そしてこの「依頼する力」は、シニアエンジニアが持っている設計力・レビュー力の言語化版に過ぎないので、組織として育成できます。コードレビューを大事にしてきた会社は、AIエージェント時代にそのまま強い、というのが半年運用しての実感です。
「AI活用が進まない」と感じている経営者・CTOの方は、ツール選定の前に社内のブリーフィング標準を整備してみてください。同じAIエージェントでも、依頼書の質で出力の質が3倍変わります。
僕らK.Platinumでは、こうしたAIエージェント運用の組織標準化を、受託開発と並行して相談されることが増えています。「Claude Code / Devin を導入したが、組織として再現できていない」あたりに困っている方は、お気軽にお声がけください。
筆者プロフィール
沼田海斗 / 株式会社K.Platinum代表
高専卒 → トヨタ → スタートアップITコンサル → 24歳で起業 → 現在3期目・27歳。17人のITコンサル組織を率いる。AI・RAG × 製造業 / 受託開発 を主戦場としています。趣味はキックボクシング。
お問い合わせ: https://k-platinum.com
K.Platinumでは、一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひエンジニア採用情報をご覧ください。