AI活用エンジニアリングの進化

最初に言葉を正す必要があります。プロジェクトエンジニアリングは、技術プロジェクトを完成させるために、要求、設計、工程、費用、調達、品質、安全、関係者の調整を統合する仕事です。建設、製造、ITなどで以前から使われてきた考え方で、生成AIの登場後に生まれた技法ではありません。AI導入でも、解決する業務を定め、責任者を決め、データ利用の許可を取り、費用対効果を測り、運用へ移すために欠かせません。

一方、プロンプトエンジニアリングは、モデルへ渡す指示と例を設計し、望む出力を安定して得る技法です。目的、背景、制約、入力、期待する出力形式を明確にし、必要なら少数の見本を示します。2020年のGPT-3が、プロンプト内の例から課題を切り替えるin-context learningを示し、2022年ごろのChain-of-Thought研究が複雑な問題を中間段階に分ける効果を示したことで、モデルの重みを変更せず指示だけで振る舞いを調整する方法が注目されました。

良いプロンプトは、長いプロンプトと同義ではありません。モデルが判断するために必要な情報を、曖昧さが少ない順序で渡すことが重要です。「良い文章を書いて」ではなく、読者、目的、文字数、含める事実、避ける表現、完成条件を示します。分類やデータ抽出なら、許されるラベルやJSON Schemaを定義します。創作なら、守るべき条件と自由に考えてよい範囲を分けます。モデルが高性能になるほど細かな言い回しへの依存は減りますが、目的と評価基準を明文化する役割は残ります。

プロンプトだけで解決できるのは、必要な情報が一回の入力に収まり、外部操作がなく、出力を人がすぐ確認できる仕事です。議事録の要約、文章の言い換え、定型分類などが当てはまります。最新の社内規程を調べる、複数ファイルを更新する、失敗を検出してやり直す仕事では、プロンプトの外側に検索、状態、ツール、検証が必要になります。ここからコンテキスト以降の設計層が重要になります。

AIプロジェクトでは両者をつなげます。プロジェクトエンジニアリングが「どの業務を、誰の責任で、どの水準まで改善するか」を決め、プロンプトエンジニアリングが「一回のモデル呼び出しに何をさせるか」を具体化します。前者を欠くと精巧なデモが業務成果につながらず、後者を欠くと要件がモデルへ正しく伝わりません。したがって、プロジェクトは進化の第一段階ではなく、全層を包む上位の管理・設計領域です。

コンテキストエンジニアリングは、モデルが一回の推論時に参照できる情報全体を選び、構造化し、更新する技法です。プロンプト本文だけでなく、システム指示、会話履歴、検索した文書、ユーザーの権限、ツールの説明、ツール実行結果、作業中の計画、メモリ、現在日時などが対象になります。Anthropicは、プロンプトエンジニアリングの自然な発展として、望む振る舞いを生む最適なコンテキスト構成を考える仕事だと説明しています。

重要な前提は、コンテキストウィンドウが大きくても注意力は無限ではないことです。大量の資料を詰め込むと、重要な条件が埋もれ、矛盾する情報が混ざり、入力費用と応答時間も増えます。良いコンテキスト設計は、可能な限り多くの情報を入れることではなく、その時点の判断に必要な高信号の情報を入れることです。検索で候補を絞り、メタデータで権限や日付を限定し、再ランキングで順序を整え、長い履歴は要約し、必要になったときだけ原文を取得します。

RAGは代表的なコンテキスト供給技術です。質問を検索クエリへ変換し、文書を検索し、関連部分をモデルへ渡します。実装では、文書をどこで分割するか、表や見出しの構造を保つか、どの埋め込みモデルを使うか、キーワード検索と意味検索をどう組み合わせるか、古い版を除外するかが品質を左右します。検索結果を渡しただけでは出典に忠実な回答になるとは限らないため、引用位置、回答不能時の振る舞い、取得精度と回答精度を別々に評価します。

長時間エージェントでは、コンテキストが実行ごとに増えます。すべてのターミナル出力や失敗ログを残すと、重要な目標が薄まります。そこで、現在の計画、完了済み項目、未解決の問題、検証結果、次の行動を構造化した作業状態として保存します。古い会話を要約するcompaction、ファイルへ進捗を残す外部メモリ、必要な箇所をその都度読むjust-in-time retrievalを組み合わせます。コンテキストは記録庫ではなく、次の判断に必要な作業台です。

コンテキストエンジニアリングはセキュリティとも直結します。検索結果やウェブページには、モデルへ不正な指示を与えるプロンプトインジェクションが混入する可能性があります。外部文書は命令ではなくデータとして区別し、ユーザー権限を越えた情報を取得せず、機密情報を不要なツールへ渡さない設計が必要です。正しさだけでなく「その情報をモデルが見てもよいか」を決めるのもコンテキスト設計です。

AIエージェントは、目標を受け取り、状況に応じて次の行動を選び、ツールを使い、結果を観測しながら仕事を進めるシステムです。単純なチャットボットは、モデルが文章を返した時点で処理が終わります。エージェントでは、検索、データベース照会、ファイル編集、メール下書き、コード実行などの行動候補があり、モデルが現在状態に応じて使い分けます。OpenAIの実務ガイドは、モデル、ツール、指示を基礎要素として挙げ、明確なガードレールの中でワークフローを制御するシステムとして説明しています。

技術的な節目の一つは、2022年のReActです。Google Researchと大学の研究者は、言語モデルの推論と外部環境での行動を交互に行わせました。考えるだけでは最新情報を得られず、行動するだけでは長期計画を保ちにくいという問題を、Reason、Act、Observationの循環で結びました。2023年にOpenAIがFunction Callingを提供すると、関数名とJSON Schemaをモデルへ示し、必要な関数と引数を選ばせる実装が普及しました。

エージェントエンジニアリングでは、どの判断をモデルに任せ、どの判断を通常のコードで固定するかが核心です。返金額の上限、アクセス権、データ形式、禁止操作は決定論的なコードで守る方が確実です。一方、利用者の意図を読み、複数の調査手段から次の手を選ぶ部分はモデルの柔軟性が役立ちます。すべてをAIに決めさせるほど高度になるわけではありません。予測不能性が価値を生む部分だけをモデルに任せます。

ツール設計も結果を大きく左右します。ツール名と説明は役割が重ならず、入力項目は明確で、戻り値は必要な情報に絞ります。読み取りと書き込みを別ツールに分け、書き込みには確認や冪等性キーを設けます。Model Context Protocol（MCP）は、AIアプリケーションがresources、tools、promptsを発見し利用するための共通境界を提供しました。ただし接続できることと、安全に利用できることは別です。ホスト側が権限、同意、認証情報、サーバー間の分離を管理します。

複数エージェントは、役割分担が明確な場合に使います。調査、実装、評価を別エージェントへ分けたり、管理役が専門エージェントをツールとして呼んだりします。並列化で時間を短縮でき、異なる観点で検査できますが、通信費用、重複作業、責任の曖昧さが増えます。Anthropicは、まず単純で組み合わせ可能なパターンから始め、必要なときだけ複雑さを増すことを勧めています。単一エージェントに適切なツールを追加するだけで十分な業務も多くあります。

ハーネスは、モデルをエージェントとして動かす外側のソフトウェアです。セッションを開始し、モデルへコンテキストを渡し、ツール呼び出しを受け、ツールを実行し、その結果をモデルへ戻し、終了まで制御します。そこにはサンドボックス、ファイルシステム、認証情報の代理、権限確認、タイムアウト、再試行、ログ、トレース、メモリ、コンテキスト圧縮、人への引き継ぎが含まれます。エージェントが「何をするか」を判断する主体なら、ハーネスは「どこで、どんな制約の下で、どう実行されるか」を保証する器です。

ハーネスという言葉は以前から強化学習や評価基盤で使われていましたが、2025年から2026年に長時間のコーディングエージェントの設計語として注目されました。Anthropicは2025年、複数のコンテキストウィンドウをまたぐ開発で、最初に環境と機能一覧を作るinitializer agentと、一つずつ実装し進捗を残すcoding agentを組み合わせる実験を公開しました。新しいセッションが前の作業を推測しなくて済むよう、進捗ファイルとGit履歴を引き継ぎに使います。

OpenAIは2026年のCodex開発事例で、リポジトリの知識をsystem of recordにし、人間が環境、意図、フィードバックループを設計する仕事へ移ったと説明しました。大きな一枚の指示書を読ませるのではなく、短い入口から必要な文書へたどれる構造にします。アーキテクチャ規則をリンターやテストで機械的に強制し、エージェントが理解しやすいエラーを返します。ハーネスはプロンプトを増やす代わりに、正しい行動が取りやすい環境を作ります。

Anthropicの2026年のハーネス設計では、planner、generator、evaluatorを使い、仕様作成、実装、品質評価を分けました。同時に、モデルが向上すると以前必要だった補助構造が不要になることも示しています。ハーネスの各部品は、モデルが単独ではできないという仮定を符号化します。モデル更新後も古い再試行や分割を残すと、品質を上げずに費用と遅延だけを増やします。そのため部品を一つずつ外すablationと継続評価が必要です。

安全なハーネスでは、モデルの「脳」、操作する「手」、永続的な「セッション」を分離します。生成コードを動かすサンドボックスに長期資格情報を置かず、必要なAPI操作は権限を限定したプロキシを通します。失敗した実行環境は捨てて再作成でき、セッションログから再開できるようにします。これにより、クラッシュ回復だけでなく、プロンプトインジェクションで認証情報を読まれる危険も減らせます。

ループエンジニアリングは、AIが目標へ向けて行動し、結果を観測し、評価し、次の行動を調整する反復過程を設計する考え方です。IBMは2026年、Goal、Action、Observation、Adjustmentを基本段階として説明し、コーディングエージェントなどを支える新しい実践領域と位置づけました。名前は新しいものの、ReActのReason・Act・Observation、制御工学のフィードバック、ソフトウェア開発のテストと修正、Anthropicのevaluator-optimizerワークフローなど、背後のパターンには長い蓄積があります。

良いループには、検証可能な目標があります。「サイトを良くする」では終わりを判定できません。「表示速度の指標を基準値以下にし、既存テストをすべて通し、変更差分をレビュー可能にする」なら、各反復の進歩を測れます。目標を小さな状態へ分解し、何が完了し、何が失敗し、次に何を試すかを永続化します。エージェント自身の「できました」という文章ではなく、ファイル、データベース、テスト結果など環境の実状態で完了を判定します。

停止条件は成功条件と同じくらい重要です。最大反復回数、時間、トークン、費用、連続失敗回数、同じ操作の反復を上限として設定します。進歩がない場合は別の方法へ切り替え、人へ引き継ぎます。外部操作には冪等性キーを使い、再試行しても二重送信や二重課金が起きないようにします。危険度の高い操作は、ループ内で自動実行せず、人の承認ノードへ移します。止まらないループは自律性ではなく障害です。

ループの評価者も設計対象です。コードならテスト、型検査、静的解析、画面比較を使えます。文章なら事実の出典、必須項目、禁止表現を検査し、品質の主観的部分は別モデルや人が評価します。同じモデルに生成と自己採点を任せると、同じ盲点を共有することがあります。決定論的検査、別の評価モデル、人の判断を組み合わせます。評価基準を厳しくするほどよいのではなく、業務上の失敗を確実に見つける基準を選びます。

ハーネスとループの違いは焦点です。ハーネスは一回の実行を可能にする環境、権限、ツール、セッションを設計します。ループは、その実行を何を根拠に繰り返し、いつ完了・中断・人へ移管するかを設計します。実装上、ループはハーネスの中心機能であり、両者を別製品に分ける必要はありません。設計レビューで問いを分けるための概念です。

グラフエンジニアリングは、2026年時点で意味が一つに定まった標準用語ではありません。AIエージェントの文脈では、第一にワークフローをノードとエッジで表す実行制御、第二に知識をエンティティと関係で表す知識グラフの設計を指す場合があります。両方ともグラフ構造を使いますが、前者は「次にどの処理を行うか」、後者は「どの情報がどの情報と関係するか」を扱います。ページや会話でこの語を使うときは、どちらの意味か明示する必要があります。

ワークフローグラフでは、調査、下書き、検証、承認、公開などをノードにし、成功、失敗、危険度、信頼度による遷移をエッジにします。LangGraphのGraph APIは、共有State、処理を行うNodes、次のノードを決めるEdgesを基本要素とします。エッジは固定でも条件付きでもよく、複数ノードを並列に実行し、チェックポイントから再開し、人の確認で中断できます。ノードはLLMに限らず、通常の関数、検索、ルール、API操作でも構いません。

単純なループは「実行して評価し、失敗なら戻る」という一つの循環です。グラフは、複数のループ、分岐、合流、並列処理、例外処理を一つの状態機械として表せます。たとえば調査不足なら検索へ戻り、法務リスクがあれば人の承認へ進み、文章品質だけが低ければ編集へ戻します。すべてを最初からやり直さず、失敗した枝だけを再実行できます。したがって、グラフはループの次に置き換わる技術ではなく、複数のループを含められる上位の制御表現です。

知識グラフは別の設計問題です。人物、組織、製品、文書をノードにし、「所属する」「開発した」「参照する」などをエッジとして保存します。Microsoft ResearchのGraphRAGは、文章からエンティティと関係を抽出し、ネットワーク分析、要約、LLMプロンプティングを組み合わせて、文書集合を広い観点から探索します。通常のベクトル検索が似た断片を見つけるのに対し、グラフは複数文書をまたぐ関係や全体テーマを扱いやすくします。

ワークフローグラフにも落とし穴があります。図が複雑になるほど制御しやすいとは限りません。状態スキーマが曖昧だと、同じデータを複数ノードが矛盾して更新します。循環経路に上限がなければ停止しません。並列ノードが同じ外部資源を書き換えると競合します。各ノードの入力、出力、副作用、再実行可能性を定義し、グラフ全体だけでなく経路ごとのテストを作ります。単純な直列処理や一つのループで十分なら、グラフ化しない判断も重要です。

実用的なAIシステムは、六つの呼び名だけでは完成しません。最初に必要なのが仕様・意図の設計です。望む成果、対象ユーザー、入力条件、受け入れ基準、禁止事項、判断責任を、モデルにも人にも読める形で残します。コーディングエージェントなら、リポジトリの入口文書、アーキテクチャ規則、完了条件、実行コマンドを整えます。意図を会話だけに置くとセッション終了時に失われ、後のエージェントはコードから目的を推測することになります。

ツールエンジニアリングは、エージェントの行動空間を設計します。ツールの名前、説明、引数、戻り値、エラー、権限、副作用、タイムアウトを整えます。幅広い万能ツールより、責任が明確で組み合わせられる小さなツールが扱いやすい場合があります。MCP、OpenAPI、JSON Schemaなどは接続と型を標準化しますが、業務上の承認やアクセス制御は別途必要です。ツールの成功レスポンスが、実世界での処理完了を意味するかも確認します。

メモリ・検索エンジニアリングは、モデル外に知識と作業状態を保存します。RAGの文書検索、短期の会話状態、長期のユーザー設定、プロジェクト進捗を同じ「メモリ」として混ぜないことが大切です。事実の知識、個人設定、実行状態には異なる保持期間と権限があります。更新方法、削除方法、出典、時間による失効を定義し、必要なときだけコンテキストへ読み込みます。

評価エンジニアリングは、変更が本当に改善かを測ります。代表的な入力だけでなく、境界例、拒否すべき例、ツール失敗、権限不足、古いデータを含むデータセットを用意します。モデルの最終回答だけでなく、選んだツール、引数、取得文書、反復回数、最終的な環境状態を記録します。Anthropicのエージェント評価解説は、会話上の成功宣言と、予約やファイルが実在するというoutcomeを分けています。

観測可能性とトレーシングは、実運用の診断に必要です。モデル呼び出し、ツール呼び出し、待ち時間、トークン、費用、状態遷移、エラー、人の介入を一つのrunとして追えるようにします。ただし、ログへ個人情報や秘密を残してはいけません。入力を無制限に保存するのではなく、監査と改善に必要な項目、保持期間、閲覧権限を決めます。可視化は派手なダッシュボードより、失敗した経路を再現できることが重要です。

セキュリティ・ガードレール・Human-in-the-loopは、能力が上がるほど重要になります。モデルの出力検査だけでなく、通常の認証、認可、最小権限、ネットワーク分離、秘密管理、サンドボックス、監査ログを使います。読み取り、提案、下書き保存、外部送信、支払いのように行動を危険度で分類し、高リスク操作には人の承認を置きます。NISTのAI RMFは、AI製品とシステムの設計、開発、利用、評価に信頼性を組み込むための枠組みを提供しています。

統合するときは、外側から内側へ責任を定義します。プロジェクト層で業務成果、利用者、責任者、予算、リスク許容度を決めます。グラフ層で調査、作成、検証、承認、公開という状態と遷移を決めます。ループ層で各状態の再試行、評価、停止、引き継ぎを決めます。ハーネス層でセッション、ツール実行、サンドボックス、資格情報、ログを管理します。エージェント層でモデルが選べる行動を定義し、コンテキスト層でその判断に必要な情報を選び、プロンプト層で個々の呼び出しを指示します。

内側から実装すると、まず一回のモデル呼び出しで最小の価値を確認できます。プロンプトと少数の評価例を作り、必要な資料が不足したらRAGを加えます。固定手順で十分なら通常のワークフローとして実装し、状況に応じた選択が必要な箇所だけエージェントへします。外部操作が増えたら権限とハーネスを強化し、繰り返しで品質が測定可能に改善するときだけループを追加します。分岐と再開が複雑になった段階でグラフを導入します。

この順序は、最初から完全自律の複数エージェントを作るより、失敗原因を特定しやすくします。単発呼び出しが失敗するなら、プロンプト、モデル、入力データを調べます。検索後に失敗するなら取得とコンテキストを調べます。誤ったツールを選ぶならツール説明とエージェント方針を調べます。長時間で崩れるならハーネスの状態管理を調べます。同じ失敗を繰り返すならループの評価と停止条件を調べます。特定経路だけ失敗するならグラフの状態遷移を調べます。

コスト設計も層ごとに行います。すべてのノードに最高性能モデルを使う必要はありません。分類や形式検査は小型モデルや通常コード、難しい統合判断は高性能モデル、機密処理はローカルモデルというように割り当てます。キャッシュ、バッチ、並列化は費用と時間を下げますが、古い結果、レート制限、競合を管理します。ループの一回当たり費用だけでなく、失敗率と平均反復回数を掛けた完了当たり費用を測ります。

運用では、モデルとハーネスを別々に版管理します。モデル更新で性能が上がる場合も、指示追従やツール選択が変わって既存経路が壊れる場合もあります。固定した評価セットと本番トレースの両方で比較し、段階的に切り替えます。設計層の名称は整理に役立ちますが、最終的に管理するのは、再現できる設定、テスト可能なコード、監査できる状態です。

例として、毎週、競合企業の公式発表を調べ、出典付きの市場調査レポートを作り、担当者の承認後に社内へ配布するシステムを考えます。プロジェクトエンジニアリングでは、対象企業、利用者、締切、品質責任者、利用可能な情報源、月額費用、配布先を決めます。成功を「レポートを生成した」ではなく、「対象企業の更新を漏れなく確認し、各主張に到達可能な一次資料を付け、担当者が承認できる下書きを期限までに作る」と定義します。

プロンプトエンジニアリングでは、読者、文体、比較軸、推測と事実の分離、引用形式、出力見出しを指定します。コンテキストエンジニアリングでは、直近一週間の公式発表、前回レポート、企業別の基礎情報、検索日時を集めます。古い記事や転載を除き、同じ発表の重複をまとめ、各段落で使う資料だけを渡します。過去の全レポートを毎回入れず、比較に必要な指標と未解決事項を構造化して保存します。

エージェントエンジニアリングでは、検索、ページ取得、日付確認、表作成、下書き保存のツールを与えます。外部送信ツールは承認前に使えないようにします。エージェントは情報不足の企業を判断して追加検索し、利用できないページでは別の公式情報源を探します。曖昧な会社名や買収関係は、人へ質問する条件を設けます。複数エージェントにするなら、企業別の調査を並列化し、統合役が重複と矛盾を処理します。

ハーネスエンジニアリングでは、検索とブラウザーを隔離環境で動かし、認証情報をモデルから分離し、取得URL、時刻、ハッシュ、ツール結果を記録します。途中で停止しても再開できるよう、企業ごとの調査状態を永続化します。ネットワーク失敗には回数を限定した再試行を行い、情報源の内容を命令として実行しないよう信頼境界を保ちます。実行時間、検索回数、モデル費用を上限管理します。

ループエンジニアリングでは、調査、下書き、検証、修正を繰り返します。URLが開けるか、発表日が期間内か、主張に引用があるか、数値が原文と一致するかを自動検査します。不足項目だけを再調査し、三回連続で情報が得られなければ「確認不能」と明記して人へ渡します。文章を無限に磨かず、必須検査を通過した時点で承認待ちへ進みます。

グラフエンジニアリングでは、開始、企業リスト取得、並列調査、重複排除、統合、引用検証、リスク判定、人の承認、配布をノードにします。引用失敗は調査ノードへ戻し、文体だけの失敗は編集ノードへ戻します。未公開情報や法的リスクが検出された場合は、自動修正を続けず法務確認へ分岐します。承認済み状態だけが配布ノードへ進めます。知識グラフを併用するなら、企業、製品、人物、提携、発表を関係として保存し、週をまたぐ変化を追えます。

この例では、各技法が別々の製品ではなく、一つの品質保証系を作っています。良いプロンプトだけでは最新情報を取得できず、RAGだけでは調査の完了を判断できず、エージェントだけでは安全な配布を保証できません。ハーネスが実行を支え、ループが検証と修正を管理し、グラフが複数経路を見える形にし、最終責任は人と組織が持ちます。

一回の生成で完了し、人がすぐ確認できるなら、プロンプトと構造化出力から始めます。必要な事実がモデル外にあるならコンテキストとRAGを追加します。手順が完全に決まっているなら、LLMを各工程の一部に使う固定ワークフローで十分です。入力によって次の行動が変わり、外部ツールを選ぶ必要があるときにエージェント化します。自律性は目的ではなく、不確実な判断を扱うための手段です。

ツール利用が本番データへ触れるなら、早い段階でハーネスの権限、秘密管理、サンドボックス、ログを整えます。長い作業や複数セッションを扱うなら、進捗状態、再開、コンテキスト圧縮を追加します。結果を測って修正すれば品質が上がる仕事にはループを使い、検証器と停止条件を先に作ります。単純に同じプロンプトを繰り返すだけでは、誤りを増幅する可能性があります。

分岐が少ない間はコード上のif文と直列処理で保ちます。複数の承認経路、並列作業、部分再実行、長時間中断が必要になったとき、状態グラフが有効です。知識グラフは、関係そのものが質問対象で、複数文書をまたぐ接続を追う必要がある場合に検討します。ベクトル検索で十分な資料へ、構築・更新費用の高い知識グラフを無理に導入する必要はありません。

導入判断は、デモの成功率ではなく、完了当たり費用、所要時間、人の確認時間、重大な誤操作率、回復率で比較します。高性能モデルへ変更して単純化できるなら、古いハーネス部品を外します。逆に、規制対象や高リスク業務では、性能が上がっても承認と監査を残します。技術の層は成熟度ランキングではなく、業務の複雑さとリスクへ応じて選ぶ道具箱です。

最終的な認識としては、「プロンプト → コンテキスト → エージェント → ハーネス → ループ → グラフ」という並びは、設計対象がモデルの一回の応答から組織的な実行システムへ広がった流れを説明するには有効です。ただし年代順の必須コースではなく、各層は重なります。プロジェクトエンジニアリングはこの列の先頭ではなく全体を包み、評価、ツール、メモリ、セキュリティ、Human-in-the-loopが横断的に支えます。この修正を加えれば、AI活用技法の変遷としてかなり正確な見取り図になります。