はじめに
概要
本記事では、AI駆動開発時代に必要な新しい思考様式・考え方といった「メンタルモデル」について、実際のプロジェクトでの事例を交えつつご紹介します。
スライドは以下で公開していますが、口頭での補足説明も多いため、ぜひ記事本文もあわせてお読みいただければと思います！
対象読者
まだ本格的にAI駆動開発を始めていない方や、AIを活用しきれていない、もしくは個人レベルでは活用してるもののチーム全体での活用に悩んでいる以下のような方を想定しています。
- AI駆動開発に興味があるエンジニア・開発者
- 生成AIを利用しているものの、まだ現場で活用しきれていないと感じている方
- 生成AIを活用した開発プロセスの最適化に関心がある方
それでは、以下本編に入ります。
AI時代の思考転換：道具から設計へ
ここではまず、なぜAI駆動開発時代においてメンタルモデルのアップデートが必要なのかという前提から説明します。
As-Is / To-Beの対比でどのように思考を変えるべきかを整理します。
As-Is：AIを「道具」として"使う"だけ
AIを単なる便利な「道具」として、その場限りで使うだけに留まっていないでしょうか？
もし以下のような状態に当てはまる方は、メンタルモデルのアップデートが必要と考えられます。
- 単発のプロンプトを投げ、その場その場での利用に留まっており、効率化に限界を感じている
- AI活用はしているものの、それが個人に閉じてしまっている
- チーム全体の生産性向上にまで繋がっていない
To-Be：AIを「パートナー」として"設計"する
As-Isの状態から脱却し、これからはAIを単なる道具ではなく「パートナー」として捉え、その働き方自体を設計していく必要があります。
- AIを開発プロセスに組み込んで、自律的に価値を生み出すサイクルを設計する
- 「AIに何をさせるか」を人間が主導権を持って決定する
- チーム全体での生産性向上の基盤を作る
つまり、私たちは単なる「AIユーザー」ではなく、「AIの可能性を最大限引き出す協働者」 を目指す必要があります。
ここがメンタルモデルの転換点になります。
人間とAIの役割再定義
協働者となるためには、まず人間とAIのそれぞれの強みを理解することが重要です。
以下、それぞれの役割について再定義します。
人間の役割
人間は目的の定義、制約や評価軸の設計、フィードバックの仕組み化、暗黙知を形式知に変えるところの役割を担います。
ゴールを与えるのはもちろん、ゴールに向かうまでの道を整備し、いかにAIが自律的に動けるかを設計することが重要です。
- 目的を定義：達成目標の明確化
- 制約/評価軸を設計：ルール/品質基準の設定
- フィードバックを仕組み化：試行と評価を次に繋げる
- 暗黙知→形式知：経験の資産化
AIの役割
それに対し、AIは生成・変換、仮説の具体化、改稿・改善、アイデアの発散といった部分に強みを持ちます。
- 生成・変換：高速な生成
- 仮説の具体化：アイデアを形に
- 改稿・改善の実施：フィードバックからの改善を実施
- アイデアの発散：複数案を高速提供
このように、それぞれの強みを把握し、役割を再定義・認知することが大切です。
AI駆動開発の基本原則
次は、AI駆動開発を実践していくための「3つの原則」について紹介します。
1. 最小限で十分な情報
まずは「最小限で十分な情報」です。
AI駆動開発において、質の高いインプットは質の高いアウトプットに直結します。
では、この「質の高いインプット」とは何かと言うと、目的・制約・参照・評価基準が明確なものです。
目的については「何を達成したいのか」を明確にし、制約については「守るべきルールや条件」、参照については「参考にすべき情報源」、評価基準については「成功の指標や品質基準」を定義します。
これらはどれか1つでも欠けると品質に影響するため、必須要素として捉える必要があります。
そして、詳細は後述しますが「コンテキストウィンドウの制約」があるため、これら全てを単に詰め込めばいいというわけではありません。あくまで最小限で十分な情報設計を行うことが重要です。
2.高速試行ループ
AIによってアウトプットするコスト自体が大幅に下がりました。
しかしまだまだ一発で完璧なアウトプットを得るのは難しいのが現状かと思います。
この状況下においては、フィードバックの速度が質に大きく影響します。
つまり、試行回数 × フィードバック速度 = 質 という関係性が成り立ちます。
プロトタイプ作成からレビュー、改善までを高速で回していきます。
ここでは一発で当てに行かずに細かく刻み、それを高速で回すという思考を持つ必要があります。
従来の「一発で完璧を目指す」思考から、「高速な試行で質を上げる」思考への転換が必要です。
3.知識の資産化
開発過程などで得た知識を継続的に貯めていくことで、それが複利となって将来的に価値を発揮します。
むやみやたらに蓄積するだけでなく、以下を意識します。
- 常にソースとドキュメントの同期をとる
- 余計な情報がノイズとならないように、時には 「捨てる勇気」 も必要
コンテキストエンジニアリング
これらの原則を実践するための中核スキルとして、次に「コンテキストエンジニアリング」について説明します。
コンテキストエンジニアリングとは
コンテキストエンジニアリングというのは単なるプロンプトの話ではありません。
「何を・いつ・どう渡す」という全体のコンテキスト設計と最適化をするのがコンテキストエンジニアリングです。
（本記事では簡潔に触れますが、より深掘りしたい方は後述の参考資料をご覧ください。）
- 何を：仕様・制約、既存コード、用語集・ドメイン知識など、目的に応じた必要な情報
- いつ：初期指示時、レビュー時、Just-in-timeなど、最適なタイミング
- どう渡す：Web検索、RAG、MCPなど、目的に応じた最適な手法
コンテキストは有限のリソース
ここで最も重要な点は、「コンテキストは有限のリソースである」と認識すること（=コンテキストウィンドウの制約）です。
トークン数が増えるほどAIの注意力は分散し、精度が低下します。コンテキストの腐敗（Context Rot） と呼ばれる現象です。
そのため、情報は常に 有益でありながら引き締められた状態を保つこと（informative, yet tight） を目指す必要があります。
ドキュメントの価値
そして、これは言い換えると、AI駆動開発時代においては 「渡す情報の価値」 が非常に重要で大きく変わってきているということです。
良いREADMEや仕様書は、AIにとって最高のコンテキストとなり、そのまま出力品質に直結します。
その中でも特に「ドキュメントの価値」という部分にフォーカスしてさらに説明を進めます。
ドキュメントの価値転換
「書く」を「資産」に変える
AIが読む前提でドキュメントを作成することで、書く行為がそのまま将来の生産性向上への投資になる、これがドキュメントの価値転換における最も重要なポイントです。
従来のドキュメント作成は「短期的な消費」が目的になりがちで、書いた後に活用されない・メンテナンスされる放置されることが多かったのではないでしょうか。
例えば会議での共有やオンボーディングのために一時的に使われ、その後は古い情報が残り続ける、という状況です。
しかし、AI駆動開発時代においては、ドキュメントはAIが読む資産として設計・作成されるべきです。
これまで（人間が読む前提）
皆さんのチームのドキュメントは、まだこの状態に留まっていないでしょうか？
- 物語的・散文的：人間が読みやすいように物語調で書く
- 会議で共有・消費：その場で共有して終わり、再利用が想定されていない
- 一度書いたら終わり：メンテナンスされず、古い情報が残り続ける
これから（AIも読む前提）
- 構造化（Markdown / XML）：AIが解析しやすい構造化された形式
- 暗黙知 → 形式知：個人の頭の中にある知識を誰でも（AIも）アクセスできる形に
- 継続的なメンテナンス・再価値化：常に最新の状態を保ち、価値を維持する
AI可読なマークダウンやXML形式で構造化し、暗黙知を形式知に変え、継続的な再価値化に取り組む必要があります。
ドキュメント資産化の実例
では、このドキュメントを資産に変えるということが、どのように効果を発揮するか実例を交えつつご紹介します。
実際に私が保守運用フェーズとして現在も継続的にご支援させていただいているプロジェクトについてです。
Before：当時の課題
体制として基本的に私1人で対応することが多く、月数時間の限られた工数で顧客折衝、ご要望の対応、不具合対応等を行っています。
元々は前任の方中心に開発・運用していたものを1年ちょっと前に引き継ぎました。
当然引き継ぎはしっかりと行い、READMEもその際に整備いただいたのですが、やはり実際に運用してみると背景情報が足りなかったり、想定していないケースが発生したりと、引き継ぎと既存ドキュメントだけではカバーしきれない部分が多々ありました。
また、複数の外部サービスと連携しているシステムであったこともあり、それぞれの仕様理解やデータフロー・変換ロジック等の把握に対する認知負荷が非常に高く、開発当初から関わっていない私にとっては全体像の把握にとても苦労しました。
（もちろん私自身の経験の未熟さもありますが…。それでもサービスが停止するような大きな問題が発生しなかったのは、しっかりとした設計・実装をされていたおかげだと感じています。）
以下に当時の課題を整理します。
当時の課題
- 属人化したナレッジ：開発メンバーの頭の中にしかない情報 / 情報格差
- 分散した情報：Googleスプレッドシートやドキュメント、Slack等の過去チャットに散在
- 厳しいリソース制約：（ほぼ）ワンマン・月数時間という運用体制
実施したこと
これに対して、2つの軸で同時並行して取り組みました。
1. ナレッジの収集・追加
- プロジェクト概要 / システム構成
- ビジネスロジック
- 不具合調査レポート
- 追加開発時の依頼背景・対応手順
人力でナレッジを収集・整理しつつ、Claude Codeが登場してからはそれを利用してリバースエンジニアリング的なドキュメント生成を行い、ナレッジの蓄積を行いました。
2. 集約・構造化
- Google Documentsで一元管理
- リポジトリの
/docsフォルダに集約
After：活用シーンと得られた価値
どうしても人の手が必要なところがあり地道で大変な作業でしたが、途中でNotebookLMやClaude Codeが登場したことで、一気にその価値が顕在化した実感がありました。
活用シーン
具体的な活用シーンとしては、以下の3つの場面で大きな効果を発揮しています。
- オンボーディング：新規メンバーの即戦力化
- 調査・開発：不具合調査や追加開発時の参照
- システム理解：データフロー・遷移図で全体俯瞰
得られた価値
そして得られた価値は以下の3つです。
- 属人知の解体：暗黙知 → AI可読な構造化資産
- 運用負荷削減：月数時間という限られたリソースでの対応力を強化
- 将来への投資：新メンバー参加時も即戦力化できる基盤
コンテキスト・試行・資産化の反復ループ
それではこれまでの話を踏まえ、AI駆動開発の全体図を整理したいと思います。
AI駆動開発は、ドキュメント資産化の行動を全ての開発フローに拡張していきつつ、以下4つのステップを高速で回し続けます。
- コンテキスト設計：まずコンテキスト設計を行い、人間が目的・制約・参照・評価基準を明確に定義し、AIへの最小限で十分な情報を準備
- AIによる生成：設計されたコンテキストをもとに、コードやドキュメント、テスト等をAIが高速に生成
- 評価・フィードバック：AI自身によるセルフレビュー、または人間がレビューを行い、改善指示を出して再度②の生成ループを回す、あるいはそこで得られた知見を次のステップに渡す
- 知識の資産化：成功や失敗のパターンを構造化し、次の①コンテキスト設計で再利用できる資産として蓄積
まとめ
AI駆動開発時代に必要な新しいメンタルモデルは以下の3つです。
- コンテキスト設計思考：コンテキストを有限なリソースと認識し、最小限で十分な情報設計を行う。何を・いつ・どう渡すかを設計することが、AI駆動開発の土台となる
- 高速な試行ループ思考：一発で当てにいかず細かく試行を高速で繰り返す。AIの生成能力を活かし、高速な反復で質を上げる
- AI可読性を前提に資産化思考：得られた知見はAIへの新たなコンテキストとして可読性を重視して資産化。暗黙知を形式知に変え、構造化された資産として蓄積する
本日お話ししたこれら3つの思考というのは、特別なスキルやツールがなくても、明日からの意識と行動で実践できるものです。
まずは皆さんのチームのREADMEやドキュメントを『AIが読む資産』としてアップデートし、AI駆動開発の第一歩を踏み出してみてはいかがでしょうか。
参考資料
登壇に使用したスライドは以下で公開しています！
コンテキストエンジニアリングについて本記事では簡潔に触れましたが、より深掘りしたい方はこちらの記事が参考になるかと思います。
Discussion