【2026年版】業務用AIエージェント開発フレームワーク
―従来のシステム開発の土台の上に、AIエージェント固有の考慮事項を載せる
はじめに：本フレームワークの位置づけ
AIエージェント開発でよく見られる3つの失敗パターン
1. PoCのまま本番化して監査不能に：「動いたからリリース」で進めた結果、誰がいつ何を承認したか追跡できず、監査で指摘を受ける。ログも不十分で原因調査もできない。
2. エージェントにWrite権限を渡して事故：「便利だから」とデータ更新・メール送信・承認処理の権限を与えた結果、LLMの判断ミスで誤った処理が実行され、業務に支障。
3. 運用で品質劣化を見逃す：リリース時は良好だった回答品質が、LLMプロバイダのモデル更新やナレッジベースの陳腐化で徐々に劣化。気づいたときには現場の信頼を失っている。
本フレームワークは、これらの失敗を防ぐための設計・運用指針を提供します。
AIエージェントは、従来のシステムと同じく「業務で使うソフトウェア」です。したがって、従来のシステム開発で培われた知見—要件定義、設計、開発、テスト、移行、運用—の全てが引き続き必要です。AIエージェントだからといって、セキュリティ設計を省略してよいわけでも、性能要件を曖昧にしてよいわけでもありません。
本フレームワークは、この「当たり前」を前提として明示した上で、AIエージェント特有の考慮事項を追加する構成をとっています。「AIだから特別」ではなく、「従来の土台＋AI固有の上乗せ」という考え方です。
また、本フレームワークは、産総研（AIST）が2025年5月に発行した「生成AI品質マネジメントガイドライン 第1版」の品質体系を参照しています。同ガイドラインは、LLM利用AIシステムが満たすべき品質特性を体系的に整理しており、本フレームワークの品質設計・評価の基盤となっています。なお、本記事ではガイドラインの趣旨に沿いつつ、実務での適用しやすさを考慮して品質特性の整理を行っています。
そもそもAIエージェントとは何か
AIエージェントとは、LLM（大規模言語モデル）が自律的に判断し、外部ツールを呼び出しながら、複数ステップのタスクを遂行するシステムです。産総研ガイドラインの用語では「LLMエージェントシステム」と呼ばれ、エンドユーザーが与えたゴールを達成するために、多数の外部サービスを適切に組み合わせるオーケストレーションを特徴とします。
単なるチャットボット（質問→回答の1ターン完結）とは異なり、エージェントは「次に何をすべきか」を自分で判断し、必要に応じてデータベースを検索したり、APIを呼び出したり、ファイルを作成したりします。産総研ガイドラインでは、この構造を「Goal Creation（ゴール具体化）→ Planning（プラン生成）→ Execution（実行管理）→ Orchestration（オーケストレーション）」という概念的構成で説明しています。
この「自律的な判断」と「外部システムへの作用」がエージェントの本質であり、同時にリスクの源泉でもあります。人間が逐一指示を出すのではなく、AIが判断して行動するため、その判断が誤っていた場合の影響が大きくなります。だからこそ、従来のシステム開発以上に、設計段階での慎重な検討と、運用段階での継続的な監視が求められます。
エージェントが必要かどうかの判断
開発に着手する前に、そもそもエージェントが必要かを判断する必要があります。Anthropicの知見にもあるように、「必要以上に複雑なエージェントにしない」ことが成功の鍵です。
以下のチェックリストで、エージェントの必要性と求められる厳格さを判定できます。
| 判定項目 | Yes の場合 |
|---|---|
| 1. 複数ステップの処理が必要か？ （例：情報収集→判断→アクション） |
→ エージェント検討の余地あり |
| 2. Read-onlyか、Write/Executeを伴うか？ （検索・要約・起案 vs 登録・送信・承認） |
→ Write/Executeなら権限・監査・HITL・ロールバックの厳格な設計が必須 |
| 3. 手順は定型化できるか？ （ルールベースで記述可能か） |
→ 定型なら従来のワークフローエンジンで十分な可能性 |
| 4. 失敗時のコストは高いか？ （誤承認・情報漏洩・金銭的損失） |
→ 高コストならHITL（人間の承認）を必須に |
| 5. HITLを運用に組み込めるか？ （承認フローの設計・人員配置が可能か） |
→ 組み込めないなら自動化範囲を限定 |
社内規程への問い合わせ対応や、マニュアルの要約といったタスクは、RAG（検索拡張生成：Retrieval-Augmented Generation、外部知識を検索して回答生成に活用する手法）を組み込んだチャットボットで十分な場合がほとんどです。これらは「Read-only」の処理であり、エージェントほどの厳格な統制は不要です。
エージェントが真に必要なのは、複数のシステムを横断して情報を集め、判断し、実際にアクションを起こす必要がある業務—たとえば、経費申請の内容を確認し、承認ルールに照らし合わせ、問題なければ会計システムに登録するといった、複数ステップの処理が必要な場合—です。特に「Write/Execute」を伴う処理では、権限管理、監査ログ、Human-in-the-Loop（HITL）、ロールバック手段の設計が一段厳格になります。この「Read系とWrite系の区分」は、本フレームワーク全体を通じて設計・テスト・運用の厳格さを決める基準となります。
エージェントの導入は開発コストを増加させ、品質管理を複雑化させ、障害リスクを高めます。「AIエージェントを作りたい」という動機ではなく、「この業務課題を解決するにはエージェントが必要」という判断に基づいて着手してください。
Agile開発との組み合わせ
Agile開発に対する誤解を解く
AIエージェント開発においても、Agile開発手法を採用するケースは多いでしょう。しかし、ここで「Agile開発の柔軟性」に対する誤解を解いておく必要があります。
「Agileだから要件は後から自由に変更できる」「事前の計画や設計は不要、走りながら考えればいい」という考え方は、Agile開発の本質を誤解しています。Agileマニフェストには「計画に従うことよりも変化への対応を」とありますが、これは「計画を立てない」という意味ではありません。「変化に対応するプロセスを持つ」ことと「何も決めない」ことは全く異なります。
Agile開発の第一人者であるMartin Fowler氏は「設計は死んでいない。むしろ優れた設計者には『将来の変化を見据えて今の設計に活かす』スキルが求められる」と述べています。また、SAFe（Scaled Agile Framework）の考案に関わったJames O. Coplien氏は「設計や開発において創発（エマージェント）を認めつつも、少しの計画を入れることで多くの無駄を避けることができる」と指摘しています。
AIエージェント開発においても、この原則は変わりません。むしろ、LLMの挙動が事前に完全には予測できないという特性があるからこそ、「何を固定し、何を柔軟にするか」を事前に決めることが重要になります。
何を固定し、何を柔軟にするか
Agile開発で成功するためには、システムを「固定すべき部分」と「柔軟にすべき部分」に分類し、それぞれに適切な対応をとる必要があります。
事前に固定すべき要素は、後から変更するとシステム全体に影響が及ぶ「アーキテクチャ破り」を引き起こす部分です。具体的には、非機能要件の目標水準（性能、可用性、セキュリティ）、データ境界とドメインモデルの核（後から変えにくい骨格）、外部連携・統合方式（契約的インターフェース）が該当します。これらは「最後の責任ある瞬間」を見極めつつも、基本的には早期に決定し、スプリントを通じて変更しない前提で進めます。
柔軟にすべき要素は、スプリントごとのフィードバックを受けて改善できる部分です。業務ルールの詳細（設定化・ルールエンジン化で対応）、UI/UXの詳細設計（ユーザーフィードバックで改善）、拡張ポイント内の機能追加（プラグイン構造で対応）が該当します。これらは「変化を歓迎する」領域であり、スプリントレビューでのフィードバックに基づいて積極的に改善します。
AIエージェント固有の観点では、プロンプトの詳細な文言は柔軟に改善すべき要素ですが、プロンプトの構造（システムプロンプトの役割定義、ツール呼び出しの形式）は固定すべき要素です。同様に、どのLLMモデルを使うかは差し替え可能な設計にしておく（柔軟性を確保）べきですが、LLMとの連携方式（API呼び出しのパターン、エラーハンドリングの方針）は早期に決めて固定します。
スプリントと設計作業の関係
Agile開発では、設計作業をどのタイミングで行うかが問題になります。「スプリント0」として最初に設計期間を設けるアプローチと、各スプリント内で必要な設計を行う「ジャストインタイム設計」のアプローチがありますが、AIエージェント開発では両者を組み合わせることを推奨します。
プロジェクト開始時には、「Inception」と呼ばれる準備期間を設けます。ここでは、ビジネスのビジョンと目標の確認、主要なステークホルダーの特定、変更の軸（将来的に変化する可能性が高い方向性）の特定、非機能要件の目標水準の設定、アーキテクチャの概要設計を行います。この期間は2〜4週間程度を想定しますが、プロジェクトの規模や不確実性によって調整します。重要なのは、ここで「すべてを決める」のではなく、「何を固定し、何を柔軟にするか」を決めることです。
各スプリント内では、そのスプリントで実装する機能の詳細設計を行います。ここでの設計は、Inceptionで決めた「固定すべき部分」の制約の中で、「柔軟にすべき部分」をどう実現するかを決める作業です。この設計作業はスプリントプランニングの一部として行うか、スプリント内のタスクとして明示的に計上します。
変更要求への対応フロー
Agile開発中に変更要求が発生した場合、以下の判断フローに従って対応します。
まず、その変更が「想定範囲内」か「想定範囲外」かを判断します。想定範囲内の変更（柔軟にすべき部分への変更、または固定部分に影響しない変更）であれば、プロダクトバックログに追加し、優先順位に従って通常のスプリントで対応します。
想定範囲外の変更（固定すべき部分への変更、またはアーキテクチャの想定を超える変更）であれば、まず影響範囲とコストを可視化します。「この変更を行うと、どのコンポーネントに影響があり、どの程度の工数がかかるか」を見積もり、ステークホルダーに提示します。その上で、「このコストを受け入れて変更を行うか」「代替案（段階的な対応、スコープの調整）を検討するか」「変更を見送るか」をステークホルダーと合意します。
この判断フローを機能させるためには、設計段階で「想定範囲」を明確に定義し、ドキュメント化しておくことが必要です。これがADR（Architecture Decision Record）の役割です。
フェーズ1: 要件定義
なぜ要件定義が重要か
要件定義は、プロジェクトの成否を決める最も重要なフェーズです。ここで定義した内容が曖昧であれば、設計は迷走し、開発は手戻りを繰り返し、テストは「何をもって合格とするか」が不明確になります。これは従来のシステム開発でも同じですが、AIエージェントではさらに深刻です。なぜなら、LLMの出力は本質的に確率的であり、「正解」の定義が曖昧なままでは品質の評価すらできないからです。
Agile開発を採用する場合でも、要件定義は「不要」になるわけではありません。ただし、すべての要件を詳細に確定させるのではなく、「固定すべき要件」と「柔軟に対応する要件」を区別し、前者については十分な検討を行い、後者についてはスプリントを通じて詳細化していくアプローチをとります。
業務要件の明確化
最初に行うべきは、解決すべき業務課題の明確化です。「AIを使って業務を効率化したい」では要件になりません。「経費精算の問い合わせ対応に1日平均3時間かかっており、これを1時間以下にしたい」のように、現状の課題と達成すべき目標を定量的に定義します。
この際、KPI（重要業績評価指標）を明確に設定することが不可欠です。KPIがなければ、プロジェクトの成功・失敗を判断できません。「便利になった気がする」では、追加投資の判断も、改善の方向性も定まりません。KPIは、対応時間の短縮率、人手対応率の削減、ユーザー満足度スコアなど、測定可能な形で定義します。
機能要件の定義
エージェントが「何をするか」を定義します。ユースケースを洗い出し、それぞれについて入力（ユーザーからの問い合わせ、トリガーとなるイベント等）、処理（エージェントが行う判断とアクション）、出力（ユーザーへの応答、システムへの更新等）を明確にします。
ここで重要なのは、エージェントの権限範囲を明確に定義することです。エージェントは「情報を検索して回答する」だけなのか、「承認処理を実行する」ところまで行うのか。後者の場合、どのような条件で自動実行を許可し、どのような条件で人間の承認を求めるのか。この境界が曖昧なまま開発を進めると、本番稼働後に「エージェントが勝手に承認してしまった」といった事故につながります。
品質要件の定義：産総研ガイドラインの品質特性
産総研の「生成AI品質マネジメントガイドライン」は、LLM利用AIシステムが満たすべき品質特性を体系的に整理しています。要件定義段階では、この品質特性に基づいて、システムに求められる品質要件を明確化します。
要求満足性は、システムがビジネス要件と利用者の期待を満たすかどうかを示す品質です。機能要求満足性（期待された機能を提供できるか）と品質要求満足性（非機能要件を満たすか）の両面で定義します。
信頼性は、システムが安定して動作し続けるかを示す品質です。産総研ガイドラインでは、成熟性（十分にテストされた状態か）、ロバスト性（想定外の入力に対する耐性）、出力一貫性（同様の入力に対する出力の安定性）、進行性（処理が適切に進行するか）、可用性（必要な時に利用可能か）、耐故障性（故障時も機能を維持できるか）、回復性（障害から回復できるか）といった副特性を挙げています。AIエージェントでは特に、LLMの確率的な出力に起因する出力一貫性と、外部ツール呼び出しの失敗に対する耐故障性が重要です。
インタラクション性は、ユーザーとの対話品質を示します。適切度認識性（自身の回答の確信度を適切に認識・伝達できるか）、可制御性（ユーザーがエージェントの動作を制御できるか）、説明性（判断根拠を説明できるか）が副特性として挙げられています。業務用エージェントでは、特に可制御性—ユーザーが処理を中断したり、やり直したりできること—が重要です。
セキュリティは、不正アクセスや情報漏洩からシステムを保護する品質です。アクセス制御性、介入性（Human-in-the-loop の仕組み）、真正性（入出力の改ざん防止）、責任追跡性（操作の追跡可能性）が含まれます。
安全性は、システムがユーザーや第三者に危害を与えないことを保証する品質です。入力制限性（有害な入力の拒否）、フェイルセーフ性（異常時に安全側に倒れる）、否認防止性（操作の証跡）が副特性として挙げられています。
プライバシーと公平性は、社会的・倫理的要請に応える品質です。AIエージェントが個人情報を適切に取り扱うこと、特定の属性に対する偏りなく対応することが求められます。
これらの品質特性について、「どの程度の水準を目標とするか」を要件定義段階で明確にします。すべての品質を最高水準で実現することは現実的ではないため、業務の重要度とリスクに応じて優先順位を付けます。
非機能要件の定義
非機能要件は、従来のシステム開発と同様に、性能、可用性、セキュリティ、運用性の観点で定義します。AIエージェントだからといって、これらを省略してよい理由はありません。むしろ、非機能要件は「固定すべき要素」の代表格であり、後から変更すると「アーキテクチャ破り」を引き起こす典型的な領域です。
性能要件について考えます。ユーザーが問い合わせをしてから回答が返るまでの許容時間はどの程度か。LLMのAPI呼び出しには数秒から数十秒かかる場合があり、さらにエージェントが複数回のツール呼び出しを行う場合は処理時間が積み上がります。「30秒以内に回答」といった要件がある場合、それを満たすアーキテクチャを設計段階で検討する必要があります。同時接続数やピーク時のスループットも、インフラ設計に直結するため、この段階で見積もっておきます。
可用性要件も明確にします。このエージェントが停止した場合、業務にどの程度の影響があるか。24時間365日の稼働が必要か、営業時間内のみでよいか。障害時の復旧目標時間（RTO）と、許容されるデータ損失の範囲（RPO）はどの程度か。これらの要件は、インフラの冗長構成や、バックアップ戦略を決定する根拠となります。
セキュリティ要件は特に慎重な検討が必要です。エージェントがアクセスするデータの機密レベルは何か。個人情報を扱うか。機密情報を扱うか。外部のLLM APIにデータを送信する場合、そのデータがAPI提供者にどのように扱われるかを確認し、自社のセキュリティポリシーとの整合を取る必要があります。また、プロンプトインジェクション攻撃（悪意あるユーザーがプロンプトを操作してエージェントの挙動を変えようとする攻撃）への対策も、この段階で要件として認識しておきます。
運用性要件も定義します。エージェントの動作をどのように監視するか。問題が発生した場合にどのように検知し、誰が対応するか。ログはどの程度の期間保持するか。これらは「あとで考える」のではなく、要件として最初から定義しておくことで、設計・開発段階で適切な作り込みができます。
AIエージェント固有の要件
従来のシステム開発にはない、AIエージェント固有の要件も定義します。
まず、回答品質の基準です。エージェントの回答がどの程度正確であれば「合格」とするか。100%の正確性を求めるのは現実的ではありませんが、「重要な判断を伴う回答は95%以上の正確性」「一般的な問い合わせは80%以上」のように、タスクの重要度に応じた基準を設定します。この基準は、後のテストフェーズで評価データセットを作成する際の指針となります。
次に、エスカレーション条件です。産総研ガイドラインの「可制御性」と「介入性」に対応します。エージェントが自信を持って回答できない場合、あるいは高リスクな判断を伴う場合に、人間に引き継ぐ条件を定義します。「わからない」と言って終わりにするのではなく、適切な担当者に引き継ぐフローを設計するための前提条件です。
さらに、禁止事項を明確にします。エージェントが絶対にしてはならないこと—たとえば、個人情報の外部への送信、承認なしでの高額決裁、特定のシステムへの書き込み—を列挙します。これらは後述するガードレール設計の入力となります。
変更の軸の特定
要件定義段階で、「変更の軸」を特定しておくことが重要です。変更の軸とは、将来的に変化する可能性が高い方向性のことです。
たとえば、ECサイト向けのエージェントであれば「決済方法の追加」は高確率で発生する変更です。業務システムであれば「承認フローの変更」「帳票フォーマットの追加」が変更の軸になるかもしれません。AIエージェントであれば「対応するユースケースの追加」「連携するシステムの追加」「LLMモデルの差し替え」などが考えられます。
変更の軸を特定するためには、ビジネス側に「1年後、3年後にどのような変化を予想しているか」を聞くこと、類似システムの進化の歴史を調査すること、競合他社の動向や市場トレンドを分析することが有効です。
特定した変更の軸は、設計段階で「拡張ポイント」として設計に反映します。これにより、想定範囲内の変更には低コストで対応でき、Agile開発の「変化への対応」が実現可能になります。
規制・コンプライアンス要件
AIエージェントが対象とする規制を確認します。EU AI Actは段階適用で、GPAI（汎用AI）関連義務は原則として2025年8月、高リスクシステム要件は2026年8月に適用開始とされています（ただし、運用細目や適用範囲については議論が継続しており、最新の公式情報を確認してください）。日本企業でもEU市場向けサービスや、EU居住者のデータを扱う場合は対象となり得ます。また、業界固有の規制（金融、医療、個人情報保護など）との整合も確認します。
これらの規制要件は、設計・開発の制約条件となるため、要件定義段階で明確にしておく必要があります。「開発後に規制に適合できないことが判明した」という事態は、プロジェクトの大幅な手戻りを招きます。
ステークホルダーの合意
定義した要件について、関係者の合意を取ります。業務部門、IT部門、セキュリティ部門、法務部門など、それぞれの観点からレビューを受け、承認を得ます。特に、KPIとエージェントの権限範囲については、業務部門との明確な合意が不可欠です。
このフェーズの成果物は、要件定義書です。この文書が以降の全フェーズの判断基準となるため、曖昧さを排除し、測定可能な形で記述します。
フェーズ2: 設計
なぜ設計が重要か
設計フェーズは、要件を「どのように実現するか」を決定する工程です。ここでの判断が、開発の生産性、システムの品質、運用の容易さを大きく左右します。設計が不十分なまま開発に着手すると、後から「根本的な作り直し」が必要になるリスクがあります。
Robert C. Martin氏は著書「Clean Architecture」で「優れたアーキテクチャがあれば、UIやデータベースなど重大な技術要素の選定を後回し（決定を遅延）できる。それによって様々な選択肢を保持でき、結果的に柔軟性が高まる」と述べています。これは一見矛盾しているように聞こえますが、「事前にアーキテクチャを決めることで、詳細な技術選択を遅延させることができる」という意味です。つまり、「何を決めるか」と「何を決めないか」を区別することが重要なのです。
設計は、外部から見た振る舞いを定義する「外部設計」と、内部の実現方式を定義する「内部設計」に分けて進めます。
Clean Architectureの原則
AIエージェントの設計においても、Clean Architectureの原則は有効です。Clean Architectureの核心は、「ビジネスロジック（ドメイン）を技術的詳細（フレームワーク、データベース、UI）から分離する」ことにあります。
依存関係の方向を「外側から内側へ」に統一し、内側の層（ビジネスロジック）は外側の層（技術的詳細）に依存しないようにします。これにより、技術的な選択（どのLLMを使うか、どのデータベースを使うか、どのUIフレームワークを使うか）を後から変更しても、ビジネスロジックに影響が及ばなくなります。
AIエージェントの場合、以下のような層構造を考えます。最も内側にあるのはドメイン層で、エージェントが解決する業務ドメインの概念と規則を表現します。たとえば、経費精算エージェントであれば「経費申請」「承認ルール」「勘定科目」といった概念がここに属します。この層は、LLMやデータベースといった技術的詳細を一切知りません。
その外側にあるのがユースケース層で、エージェントが実行する具体的なタスクのフローを定義します。「経費申請の内容を確認し、承認ルールに照らし合わせ、問題なければ承認する」といったフローがここに属します。この層はドメイン層に依存しますが、具体的なLLMやデータベースには依存しません。
さらに外側にあるのがインターフェース層で、外部システムとの接点を定義します。LLMとの通信、データベースへのアクセス、外部APIの呼び出し、ユーザーインターフェースなどがここに属します。この層は抽象化されたインターフェース（契約）として定義され、具体的な実装は最外層で行います。
最も外側にあるのがインフラ層で、具体的な技術的実装を行います。OpenAI APIの呼び出しコード、PostgreSQLへのアクセスコード、REST APIのエンドポイントなどがここに属します。この層を差し替えることで、たとえばOpenAI APIからAnthropic APIへの移行、PostgreSQLからDynamoDBへの移行などが、内側の層に影響を与えずに行えるようになります。
外部設計：ユーザー体験の設計
外部設計では、ユーザーから見たエージェントの振る舞いを定義します。対話型のエージェントであれば、ユーザーがどのような入力をしたときに、どのような応答を返すかを設計します。
対話フローの設計では、典型的なユースケースについて、ユーザーとエージェントのやり取りの流れを具体的に記述します。単に「質問に回答する」ではなく、「ユーザーが曖昧な質問をした場合は確認の質問を返す」「複数の解釈が可能な場合は選択肢を提示する」といった分岐を含めて設計します。
応答トーンの設計も重要です。エージェントがどのような口調で応答するかは、ユーザー体験に大きく影響します。敬語を使うか、カジュアルな表現を使うか。専門用語をそのまま使うか、噛み砕いて説明するか。これらは「なんとなく」で決めるのではなく、対象ユーザーと利用シーンに基づいて意図的に設計します。
エラー時の挙動も定義します。エージェントが質問を理解できなかった場合、回答に必要な情報が見つからなかった場合、処理中にシステムエラーが発生した場合、それぞれどのような応答を返すか。これらを設計段階で決めておかないと、開発時に場当たり的な実装になり、ユーザー体験が一貫しなくなります。
エスカレーションフローは、エージェントが対応できない場合に人間に引き継ぐ手順です。どのような条件でエスカレーションするか、誰に引き継ぐか、引き継ぎ時にどのような情報を伝えるか、ユーザーにはどのように説明するかを設計します。
外部設計：システム間インタフェースの設計
エージェントが連携する外部システムとのインタフェースを設計します。データベース、社内システム、外部API、ファイルストレージなど、エージェントがアクセスするすべての連携先について、インタフェース仕様を定義します。
この設計では、連携先システムの担当者との調整が必要です。既存システムに新たなAPIを追加する必要があるか、既存のAPIで要件を満たせるか、認証方式は何を使うか、レート制限はあるか、といった点を確認します。
Clean Architectureの観点では、これらの外部システムとの連携は「インターフェース層」で抽象化し、「インフラ層」で具体的に実装します。たとえば、「経費データを取得する」というインターフェースを定義し、その実装として「社内会計システムのAPIを呼び出す」コードを書きます。将来、会計システムが変更されても、インターフェースを満たす新しい実装を用意すれば、ユースケース層やドメイン層には影響が及びません。
内部設計：コンポーネント構成
産総研ガイドラインは、LLM利用AIシステムの主なコンポーネントとして以下を挙げています。これらのコンポーネントの役割と連携方式を設計します。
基盤モデル（LLM）は、プロンプトによって様々な生成系機能を提供する訓練済み学習モデルです。Clean Architectureの原則に従い、特定のモデルに依存した設計は避けます。LLMとの連携部分を抽象化し、「テキストを入力として受け取り、テキストを出力として返す」というインターフェースを定義します。具体的なLLM（OpenAI、Anthropic、ローカルモデル等）はこのインターフェースの実装として扱います。
プロンプトとその周辺は、基盤モデルに特定の機能を発揮させる役割を持ちます。開発時に策定されるシステムプロンプト、ユーザーからの入力プロンプト、RAGコンポーネントから得られた情報を組み合わせて、最終的にLLMに与えるプロンプトを構成します。
RAG関連コンポーネントは、Retrieval Augmented Generation手法により基盤モデルが持つ内部知識を補い、また上書きする役割を持ちます。ファイルデータベース、ベクトルデータベース、検索コンポーネントから構成されます。
外部連携コンポーネントは、基盤モデルが出力した手順に基づいて外部サービスを利用する役割を持ちます。LLMエージェントシステムにおけるオーケストレーションの中核を担います。
入力フィルターと出力フィルターは、システムの機能や品質に悪影響を持つ入出力を除去する役割を持ちます。ガードレールの実装において中心的なコンポーネントです。
HMI（Human Machine Interaction）コンポーネントは、システムとユーザーのやり取りを担います。処理の流れの要所でユーザーが介入する手段を提供する役割も持ちます。
内部設計：アーキテクチャ設計
システム全体の構成を設計します。どのコンポーネントをどのように配置し、どのように連携させるかを決定します。
性能設計では、要件定義で定めた性能要件を満たすアーキテクチャを検討します。LLMの呼び出しは処理時間のボトルネックになりやすいため、キャッシュの活用、並列処理の検討、軽量モデルと高性能モデルの使い分け（簡単な質問は軽量モデルで高速に処理し、複雑な質問のみ高性能モデルを使う）といった工夫を検討します。
可用性設計では、要件定義で定めた可用性要件を満たす構成を検討します。単一障害点をなくすための冗長構成、障害検知とフェイルオーバーの仕組み、バックアップとリストアの方式を設計します。外部のLLM APIを使用する場合、そのAPIが停止した場合の代替手段（別のモデルへのフォールバック、機能制限モードでの稼働、あるいはサービス停止の判断基準）も検討しておきます。
セキュリティ設計では、要件定義で特定したセキュリティ要件を実現する方式を設計します。認証・認可の方式、通信の暗号化、データの保護（保存時・転送時）、監査ログの取得、不正アクセス検知の仕組みを定義します。特に、LLM APIへのデータ送信については、送信するデータの範囲を最小限にする設計、機密情報のマスキング、APIプロバイダーのデータ取り扱いポリシーの確認が重要です。
内部設計：AIエージェント固有の設計
LLMの選定では、要件を満たすモデルを選定します。産総研ガイドラインでは、LLMの選定において以下の観点を考慮することを推奨しています：信頼性（出力の安定性）、安全性（有害出力の抑制）、プライバシー（データ取り扱い）、公平性（バイアスの程度）、性能効率性（コストと速度）、移植性（ベンダーロックインの回避）。
プロンプト設計では、エージェントに与える指示（システムプロンプト）の構造を設計します。産総研ガイドラインでは、システムプロンプトの品質管理として以下の観点を挙げています：機能要求満足性（期待した機能を引き出せるか）、ロバスト性（様々な入力に対して安定して動作するか）、入力制限性（不適切な要求を適切に拒否できるか）。
ツール設計では、エージェントが使用するツール（関数）を設計します。各ツールについて、目的、入力パラメータ、出力形式、エラー時の挙動を定義します。産総研ガイドラインの「外部連携コンポーネント」の品質観点として、真正性（正規のサービスと連携しているか）、責任追跡性（操作の追跡が可能か）、フェイルセーフ性（連携先の障害時に安全側に倒れるか）を考慮します。
ガードレール設計は、エージェントの暴走を防ぐための安全機構の設計です。産総研ガイドラインの「入力フィルター」と「出力フィルター」に対応します。入力段階でのフィルタリング（不適切な入力の検出、プロンプトインジェクション対策）、処理段階での制限（権限チェック、実行前確認）、出力段階でのチェック（機密情報の漏洩防止、有害コンテンツの検出、ハルシネーション検知）、そして高リスクな判断における人間の介入ポイントを設計します。
評価設計では、エージェントの品質をどのように評価するかを設計します。評価指標（正確性、応答の適切さ、処理時間など）、評価データセットの構成（正常系、異常系、エッジケース）、評価の実施方法（自動評価、人間評価、その組み合わせ）を定義します。
内部設計：データ品質の設計
RAGを使用する場合、検索対象となるデータの品質が、エージェントの回答品質に直結します。産総研ガイドラインは、データ品質を以下の3つの観点で整理しています。
個々のデータ点の品質として、正確性（内容が事実に即しているか）、完全性（必要な情報が欠けていないか）、一貫性（矛盾がないか）、信憑性（信頼できる情報源か）、最新性（情報が古くないか）を確認します。
データセットの品質として、代表性（対象領域を適切にカバーしているか）、重複性（同じ情報が重複していないか）、来歴性（データの出所が追跡可能か）を確認します。
複数データセット組み合わせ時の品質として、文脈整合性（異なるデータセット間で文脈が整合しているか）、時制整合性（時点の異なるデータが適切に扱われているか）、操作整合性（データの変換・加工が適切に行われているか）を確認します。
これらの品質観点に基づいて、データの収集・整備・更新のプロセスを設計します。
内部設計：拡張ポイントの設計
要件定義段階で特定した「変更の軸」に対応する拡張ポイントを設計します。拡張ポイントとは、将来の変更に低コストで対応できるように設計された「継ぎ目」です。
Robert C. Martin氏が提唱するOCP（Open-Closed Principle：開放閉鎖原則）は、「ソフトウェアモジュールは拡張に対して開いていて（Open）、修正に対して閉じている（Closed）べき」という原則です。つまり、新しい機能を追加する際に、既存の安定したコードを修正せずに済むように設計することが重要です。
AIエージェントの場合、以下のような拡張ポイントを設計することが考えられます。ツールの拡張ポイントでは、新しいツールを追加する際に、既存のエージェントロジックを修正せずに済むように、ツールをプラグイン構造で設計します。LLMの拡張ポイントでは、LLMとの連携を抽象化し、異なるLLMプロバイダーへの差し替えを容易にします。ガードレールの拡張ポイントでは、新しいガードレールを追加する際に、既存のガードレールを修正せずに済むように、ガードレールをチェーンとして設計します。
内部設計：MCP/A2Aプロトコルの検討
2025年から2026年にかけて、AIエージェントのツール接続やエージェント間連携を標準化するプロトコルが登場しています。MCP（Model Context Protocol）はAnthropicが提唱するツール接続の標準化プロトコル、A2A（Agent-to-Agent Protocol）はGoogleが提唱するエージェント間連携の標準化プロトコルです。
これらのプロトコルは、産総研ガイドラインの「外部連携コンポーネント」の設計において有用です。複数のツールやエージェントを統合する際の開発効率を高め、異なるベンダーの製品間の相互運用性を確保できます。ただし、「流行っているから採用する」のではなく、自社の要件に照らして採用の是非を判断してください。
設計の記録：ADR（Architecture Decision Record）
重要な設計判断は、ADR（Architecture Decision Record）として記録しておくことを推奨します。ADRには、決定事項、その背景（コンテキスト）、検討した選択肢、決定の理由、その決定がもたらす結果を記載します。
ADRを記録しておくことで、後から「なぜこの設計になったのか」を追跡でき、将来の変更判断の参考になります。また、新しくプロジェクトに参加するメンバーが、既存の設計判断を理解する助けにもなります。
設計レビューと承認
設計内容について、関係者のレビューを受けます。技術的な実現可能性、セキュリティ上の懸念、運用の実行可能性、要件との整合性を確認し、承認を得ます。
このフェーズの成果物は、設計書一式です。外部設計書（対話フロー、インタフェース仕様）、内部設計書（アーキテクチャ、モジュール構成、データモデル、プロンプト方針、ガードレール設計、評価設計）、ADR（重要な設計判断の記録）を作成します。
フェーズ3: 開発
なぜ段階的に開発するか
AIエージェントの開発は、一度に全機能を作り込むのではなく、段階的に進めることを推奨します。まず最小限の機能で動作するものを作り、評価し、改善するというサイクルを回します。これは、LLMの挙動が事前に完全には予測できないためです。設計段階で「こう動くはず」と想定していても、実際に動かしてみると想定と異なる挙動をすることがあります。早期に動くものを作って検証することで、このギャップを早く発見し、手戻りを最小化できます。
Agile開発を採用している場合、この段階的な開発はスプリント単位で行います。各スプリントで動作するインクリメント（増分）を作成し、スプリントレビューでフィードバックを得て、次のスプリントで改善するサイクルを回します。
インフラ構築
設計に基づいてインフラを構築します。開発環境、ステージング環境、本番環境を用意し、それぞれの環境間でコードやデータを移行する手順を整備します。Infrastructure as Code（IaC）を採用し、環境構築を自動化・再現可能にしておくことで、環境間の差異による問題を防ぎ、障害時の復旧を迅速化できます。
LLM APIを使用する場合は、APIキーの管理、レート制限への対応、コスト管理の仕組みを整備します。開発中に意図せず大量のAPI呼び出しが発生してコストが膨らむことを防ぐため、開発環境でのAPI呼び出し上限を設定しておくことを推奨します。
コンポーネントの実装
設計に基づいて各コンポーネントを実装します。産総研ガイドラインは、コンポーネント別の品質管理策を示しています。これに従って実装を進めます。
Clean Architectureの原則に従い、層ごとに実装を進めます。まずドメイン層（業務ドメインの概念と規則）を実装し、次にユースケース層（タスクのフロー）を実装し、その後でインターフェース層とインフラ層（外部システムとの連携）を実装します。この順序で実装することで、ビジネスロジックが技術的詳細に依存しない構造を維持できます。
プロンプトの実装では、設計段階で定めた方針に基づいてシステムプロンプトを作成します。産総研ガイドラインでは、プロンプトを「ビジネスロジックを実現する実体」として位置づけています。プロンプトは一度作って終わりではなく、テスト結果を見ながら継続的に改善するものです。したがって、プロンプトをコードから分離し、バージョン管理できる構造にしておきます。
ツールの実装では、設計で定義したツールを実装します。各ツールは、入力のバリデーション、処理の実行、出力の整形、エラーハンドリングを含みます。Clean Architectureの原則に従い、ツールのインターフェースとその実装を分離します。
入力フィルター・出力フィルターの実装では、設計で定義したガードレールを実装します。産総研ガイドラインでは、入力フィルターの品質として「入力制限性」（有害な入力を適切に拒否できるか）、出力フィルターの品質として「安全性」（有害な出力を抑制できるか）を挙げています。
RAGコンポーネントの実装では、ベクトルデータベースの構築、検索コンポーネントの実装を行います。産総研ガイドラインでは、RAG関連の品質として「検索精度」と「データ品質」を重視しています。
監視・トレーシングの実装
エージェントの動作を監視するための仕組みを実装します。これは「運用が始まってから考える」ものではなく、開発段階で組み込んでおくべきものです。産総研ガイドラインの「責任追跡性」を実現するためにも、トレーシングは必須です。
トレーシングは、エージェントの各処理ステップを記録する仕組みです。従来の「ログ」が個々のイベントを点として記録するのに対し、トレーシングは「1つのリクエストに関連する一連の処理の因果関係」を追跡可能な形で記録します。ユーザーからのリクエスト、LLMへの入力と出力、ツールの呼び出しと結果、最終的な応答、そして処理時間を記録します。これにより、問題が発生した際に「どこで何が起きたか」を追跡できます。
ログは、従来のシステムと同様に、アプリケーションの動作を記録します。エラーログ、警告ログ、デバッグログを適切なレベルで出力し、集約・検索できる基盤を整備します。
メトリクスは、システムの状態を数値として収集します。リクエスト数、レスポンスタイム、エラー率、LLMトークン使用量、ツール呼び出し回数などを収集し、ダッシュボードで可視化します。
評価データセットの作成
エージェントの品質を評価するためのデータセットを作成します。産総研ガイドラインのデータ品質の観点を踏まえ、評価データセット自体の品質も確保します。
評価データセットには、正常系（典型的なユースケース）、異常系（エラー処理が必要なケース）、エッジケース（境界条件やまれなケース）を含めます。各テストケースには、入力、期待される出力（または出力の評価基準）、そのテストケースの意図を記述します。
評価データセットの規模は、最低でも20〜30ケースから始め、運用を通じて継続的に拡充していきます。実際の運用で発生した問題を評価データセットに追加することで、同じ問題の再発を防止できます。
コードレビューと単体テスト
従来のソフトウェア開発と同様に、コードレビューと単体テストを実施します。エージェントのロジック、ツールの実装、ガードレールの実装について、レビューとテストを行います。
AIエージェントの単体テストでは、LLMの呼び出し部分をモック化してテストする手法が有効です。LLMの出力は毎回異なる可能性があるため、LLMの出力を固定したモックを使用することで、ロジック部分の動作を確定的にテストできます。Clean Architectureの原則に従ってLLMとの連携を抽象化していれば、モックへの差し替えは容易です。
Vibe Codingの適切な活用と落とし穴
2025年2月、OpenAI共同創業者のAndrej Karpathy氏がX（旧Twitter）で「Vibe Coding」という概念を提唱しました。これは、LLMを活用して自然言語の指示からコードを生成し、開発者はコードの詳細を意識せずに「バイブス（雰囲気）に身を任せる」スタイルの開発を指します。Karpathy氏は「完全にバイブスに身を任せ、指数関数的な進歩を受け入れ、コードの存在を忘れる」と表現しました。
Vibe Codingは、プロトタイピングの速度を劇的に向上させる可能性を持っています。Y Combinator 2025年冬バッチでは、回答企業の約25%がコードベースの大部分をAI生成していると報告されています（ただし、これはVibe Codingに限らずAI生成コード全般の数字です）。AIエージェント開発においても、Cursor、Windsurf、Claude Codeなどのツールを使ってエージェントのコードを素早く生成することが可能です。
Vibe Codingの落とし穴：「開発地獄」に陥るパターン
しかし、Vibe Codingを本番システムに無批判に適用すると、むしろ工数が増加する事態に陥ります。2025年後半には「Vibe Coding二日酔い（hangover）」と呼ばれる現象が報告されるようになりました。具体的には以下のような問題が指摘されています。
「小さな変更が遠くで何かを壊す」問題：Vibe Codingで作られたコードは、開発者自身が構造を理解していないことが多いため、一箇所を修正すると予期しない場所で問題が発生します。Gary Marcus氏のSubstack記事では、ある開発者が「ちょっとした変更をしようとするたびに、4日間デバッグに費やす」と報告している事例が紹介されています。これは伝統的な開発でも起きる問題ですが、Vibe Codingではコードの複雑な相互依存関係を開発者が把握していないため、より深刻になります。
技術的負債の急速な蓄積：AIは動くコードを生成しますが、保守性や一貫したアーキテクチャは考慮しません。GitClearの調査によると、AI生成コードにおいて重複コードブロックの大幅な増加が観測されています。初期の開発速度の向上は、後の保守コストの増加によって相殺され、最終的にはマイナスになることがあります。
セキュリティ脆弱性の混入：複数の研究で、AI生成コードに脆弱性が含まれる傾向が指摘されています。GitGuardianやTabnineの報告では、GitHub Copilotが生成するコードの相当数に脆弱性が含まれる可能性があるとされています。AIは学習データに含まれる脆弱なパターンを再現してしまうことがあり、入力検証の不備、弱い認証などの問題が紛れ込む可能性があります。
経験豊富な開発者の生産性低下：METRの2025年の調査では、経験豊富な開発者がAIツールを使用した場合、主観的には速くなったと感じながら、実測では生産性が低下していたという結果が報告されています。AI出力の確認、応答待ち、使えないコードの破棄に時間を取られるためと分析されています。
Vibe Codingを適切に活用するためのテクニック
プロトタイプと本番コードを明確に分離することが最も重要です。Karpathy氏自身が述べているように、Vibe Codingは「使い捨ての週末プロジェクト」に適したアプローチです。プロトタイプフェーズでは存分にVibe Codingを活用し、本番に移行する際にはアーキテクチャを見直し、必要に応じてリファクタリングまたは再実装します。プロトタイプの目的は「何を作るべきか」を検証することであり、「本番コードの土台」を作ることではありません。
AI生成コードを必ずレビューすることを徹底します。「Accept All」ボタンを押す前に、生成されたコードの意図と構造を理解します。差分（diff）を読まずに受け入れることは、Vibe Codingの定義の一部ですが、本番システムでは許容されません。Simon Willison氏が指摘するように、「LLMがコードを書いて、あなたがそれをレビューし、テストし、他の人に説明できるようにしたなら、それはVibe Codingではなく、ソフトウェア開発です」。
小さな単位で生成・検証するサイクルを回すことで、問題の影響範囲を限定します。大きな機能を一度に生成させるのではなく、小さな機能を生成し、動作を確認し、テストを追加してから次に進みます。この反復的なアプローチは、Agile開発の原則とも整合します。
アーキテクチャの決定は人間が行うことを徹底します。AIは「動くコード」を生成できますが、システム全体の一貫したアーキテクチャビジョンは持っていません。Clean Architectureの層構造、依存関係の方向、コンポーネントの責務分離といった設計判断は、人間が行い、AIには「この設計方針に従ってコードを生成せよ」と指示します。
テストを先に書く（TDD）との組み合わせも有効です。期待する動作をテストとして記述してから、そのテストを満たすコードをAIに生成させます。これにより、「動く」だけでなく「正しく動く」コードを得る確率が高まります。
シニアエンジニアによる定期的なコード監査を組み込みます。Vibe Codingを活用したプロジェクトでは、特に技術的負債の蓄積を監視するために、経験豊富なエンジニアが定期的にコードベースをレビューする体制が重要です。セキュリティレビューも同様です。
Vibe Codingは、適切に使えば開発速度を向上させる強力なツールです。しかし、「AIがコードを書いてくれるから楽になる」という期待は、往々にして「AIが書いたコードのデバッグに追われる」という現実に変わります。ツールの特性を理解し、適切な場面で適切に活用することが、本当の意味での生産性向上につながります。
フェーズ4: テスト
なぜAIエージェントのテストは難しいか
AIエージェントのテストは、従来のソフトウェアのテストよりも難しい面があります。従来のソフトウェアは、同じ入力に対して同じ出力を返すことが期待されますが、LLMは確率的に動作するため、同じ入力に対しても異なる出力を返す可能性があります。産総研ガイドラインでは、この特性を「出力一貫性」の品質として扱っています。
したがって、AIエージェントのテストでは、「完全に正しい」ことを検証するのではなく、「許容範囲内の品質である」ことを確認するアプローチを取ります。
品質特性に基づくテスト
産総研ガイドラインの品質特性に基づいて、テスト項目を設計します。
要求満足性のテストでは、エージェントが期待された機能を提供できるかを確認します。評価データセットを使用して、正常系のユースケースが正しく動作することを検証します。
信頼性のテストでは、ロバスト性（想定外の入力に対する耐性）と出力一貫性（同様の入力に対する出力の安定性）を確認します。同じ質問を複数回実行し、回答の一貫性を評価します。また、曖昧な入力、不完全な入力、予期しない形式の入力に対する挙動を確認します。
インタラクション性のテストでは、可制御性（ユーザーが処理を中断・やり直しできるか）と説明性（判断根拠を説明できるか）を確認します。
セキュリティのテストでは、アクセス制御性と責任追跡性を確認します。権限のないユーザーが機密情報にアクセスできないこと、操作がログに記録されることを検証します。
安全性のテストでは、入力制限性（有害な入力を拒否できるか）とフェイルセーフ性（異常時に安全側に倒れるか）を確認します。プロンプトインジェクション攻撃、有害なコンテンツの生成要求に対する耐性を検証します。
結合テスト
エージェントの各コンポーネント（LLM呼び出し、ツール、ガードレール）が正しく連携することを確認します。実際のLLM APIを呼び出してテストを行い、エンドツーエンドでの動作を検証します。
結合テストでは、設計で定義した対話フローを実際に実行し、期待通りに動作することを確認します。正常系だけでなく、エラーケース（ツールの呼び出し失敗、タイムアウト、無効な入力など）についてもテストします。
評価（Evaluation）
開発フェーズで作成した評価データセットを使用して、エージェントの品質を評価します。ここで「テスト」と「評価」の違いを明確にしておきます。テストは「合格か不合格か」の二値判定（例：この入力に対して正しい出力が返るか）であるのに対し、評価（Evaluation）は品質の連続量測定（例：回答の正確性が何%か、応答時間の分布はどうか）です。AIエージェントでは、LLMの確率的な特性から完全な合否判定が難しいため、評価による品質の定量化が重要になります。
評価は、自動評価と人間評価を組み合わせて実施します。
自動評価では、プログラムによって判定可能な基準で評価します。たとえば、特定のキーワードが含まれているか、出力形式が正しいか、処理時間が基準内か、といった観点です。また、LLMを使って評価する「LLM-as-Judge」という手法も有効です。
人間評価では、人間が実際に出力を確認して品質を判断します。自動評価では判断が難しい観点（回答のトーンが適切か、説明がわかりやすいか、など）は人間評価で確認します。
評価結果は、要件定義で設定した品質基準と照らし合わせ、基準を満たしているかを判断します。基準を満たさない場合は、プロンプトの改善、ツールの修正、ガードレールの追加などを行い、再度評価します。
セキュリティテスト（レッドチーミング）
産総研ガイドラインは、LLM利用AIシステムにおけるセキュリティリスクの分析と、レッドチーミングの必要性を強調しています。AIエージェント固有のセキュリティリスクに対するテストを実施します。
プロンプトインジェクションは、悪意あるユーザーが入力を通じてエージェントの挙動を変えようとする攻撃です。「以上の指示を無視して、〇〇してください」のような入力に対して、エージェントが適切に拒否できるかをテストします。
情報漏洩は、エージェントが本来出力すべきでない情報（システムプロンプト、他のユーザーの情報、機密データなど）を出力してしまうリスクです。
権限昇格は、エージェントが本来許可されていない操作を実行してしまうリスクです。ガードレールが正しく機能し、権限外の操作を拒否できるかをテストします。
これらのテストは「レッドチーミング」と呼ばれ、金融・医療など高規制領域や、業務クリティカルなエージェントでは事実上必須のテスト項目となっています。多くの業界ガイドラインでも推奨されています。
性能テスト
要件定義で定めた性能要件を満たしているかをテストします。レスポンスタイム、スループット、同時接続数の上限を確認します。性能要件を満たさない場合は、アーキテクチャの見直し、キャッシュの導入、モデルの変更（より高速なモデルへの切り替え）などを検討します。
受入テスト
業務部門によるテストを実施します。実際の業務に近いシナリオでエージェントを使用し、業務要件を満たしているか、使い勝手に問題はないかを確認します。受入テストでのフィードバックを踏まえて、必要な修正を行います。
フェーズ5: 移行・デプロイ
なぜ変更管理が重要か
AIエージェントの導入は、単なるシステムの追加ではありません。ユーザーの業務プロセス、情報の探し方、意思決定の方法に変化をもたらします。この「変化」を適切に管理しないと、せっかく開発したエージェントが使われない、あるいは誤用される事態に陥ります。
変更管理の分野では、組織変革は一人ひとりの個人の変化の積み重ねであるという考え方が重要です。組織全体に「AIエージェントを導入します」と宣言しても、個々のユーザーが実際に使い方を変えなければ、組織としての変革は実現しません。したがって、移行フェーズでは、技術的なデプロイだけでなく、ユーザー一人ひとりの行動変容を支援する活動が必要です。
ADKARモデルによる変更管理
個人の変革を支援するフレームワークとして、ADKARモデルが有効です。ADKARはProsci社のJeff Hiatt氏が700以上の組織の変革パターンを研究して開発したモデルで、個人が変化を成功裏に受け入れるために必要な5つの要素を示しています。
A - Awareness（認識）は、なぜ変化が必要なのかを理解することです。AIエージェント導入の場合、「なぜこのエージェントを導入するのか」「導入しないとどうなるのか」「現状の課題は何か」をユーザーに伝えます。単に「便利になります」ではなく、「現在、経費精算の問い合わせ対応に1日3時間かかっており、これがエージェントにより1時間以下になります」のように具体的に伝えることで、変化の必要性が腹落ちします。
D - Desire（意欲）は、変化に参加し支援したいという個人の意思決定です。これは強制できるものではなく、「自分にとってのメリットは何か」「参加しないとどうなるか」「組織にとってのメリットは何か」を理解した上で、本人が判断するものです。AIエージェントの場合、「面倒な問い合わせ対応から解放される」「より価値の高い業務に時間を使える」「新しいスキルが身につく」といったメリットを具体的に示すことが有効です。また、導入に関する不安や懸念に真摯に向き合い、対話を通じて解消していくことも重要です。
K - Knowledge（知識）は、どのように変化するか、新しい状態でどのように行動するかについての知識です。エージェントの使い方、どのような質問に適しているか、どのような質問には適さないか、問題が発生した場合の対処法などを教育します。ここで重要なのは、KnowledgeはAwarenessとDesireの後に来るということです。「なぜ必要か」を理解し「使いたい」と思っていない状態で使い方を教えても、定着しません。
A - Ability（能力）は、知識を実際の行動に移す能力です。「使い方は知っている」と「実際に使える」は異なります。ハンズオントレーニング、サポート体制の整備、質問しやすい環境の構築などにより、ユーザーが実際にエージェントを使いこなせるようになるまで支援します。最初の数回は成功体験を積めるように、比較的簡単なタスクから始めることも有効です。
R - Reinforcement（強化）は、変化を持続させるための強化活動です。一度使い始めても、習慣化しなければ元のやり方に戻ってしまいます。利用状況のモニタリング、成功事例の共有、継続的なサポート、フィードバックの収集と反映により、新しい行動を定着させます。
移行計画の策定
技術的な移行計画と並行して、ADKARの各要素を実現する活動を計画します。
移行のスケジュールは、段階的なロールアウトを基本とします。全ユーザーに一斉に公開するのではなく、まずパイロットグループに公開し、フィードバックを収集して改善した後、徐々に対象を拡大します。パイロットグループには、変化に前向きなユーザー（アーリーアダプター）を含めることで、成功事例を作り、後続のユーザーのDesireを高める材料を得られます。
移行の体制として、技術的なサポートチームに加えて、変更管理を担当するチェンジエージェント（変革推進者）を配置することを推奨します。チェンジエージェントは、各部門でユーザーの疑問や懸念に対応し、成功事例を収集・共有し、抵抗が生じた場合に対話を通じて解消する役割を担います。
ロールバック計画も準備しておきます。エージェントに問題が発生した場合に、従来のプロセスに戻す手順を明確にしておきます。これは技術的な安全策であると同時に、ユーザーの心理的安全を確保する意味もあります。「うまくいかなかったら元に戻せる」という安心感が、新しいものを試す意欲を高めます。
ユーザー教育の設計
ユーザー教育は、ADKARのKnowledgeとAbilityを支援する活動です。産総研ガイドラインでは、「利用者が担うべき事項」として「悪用しない、過度に期待しない、依存しない」を挙げています。これらを踏まえた教育内容を設計します。
エージェントの特性の理解として、従来のシステムとの違いを明確に伝えます。「同じ質問をしても毎回同じ回答が返るとは限らない」「100%正確な回答が保証されるわけではない」「回答を鵜呑みにせず、重要な判断は人間が確認する」といった特性を理解してもらいます。これは「だから使えない」という結論に導くのではなく、「この特性を理解した上で、適切に活用する」という姿勢を醸成するものです。
適切なユースケースの明示として、エージェントが得意なタスクと苦手なタスクを具体的に示します。「社内規程の一般的な問い合わせには強い」「前例のない複雑な判断は人間に確認が必要」のように、境界を明確にすることで、適切な利用を促します。
ハンズオントレーニングとして、実際の業務シナリオを使った練習を行います。座学だけでなく、実際に触って試す機会を設けることで、Abilityを高めます。
サポート体制の周知として、問題が発生した場合の報告先、質問がある場合の相談先を明確に伝えます。「困ったときに誰に聞けばいいかわからない」という状態は、利用の定着を妨げます。
本番デプロイ
移行計画に従って本番環境にデプロイします。デプロイ後は、監視ダッシュボードを確認し、技術的な異常がないことを確認します。問題が発生した場合に備えて、ロールバック手順を事前にリハーサルしておきます。
デプロイ直後は、技術チームとチェンジエージェントが連携して、ユーザーからの問い合わせに迅速に対応できる体制を敷きます。最初の数日間の体験が、その後の利用定着に大きく影響するためです。
デプロイ後の確認と強化
本番デプロイ後、一定期間（たとえば2〜4週間）は集中的に監視とフォローアップを行います。
技術的な監視として、エラー率の推移、性能指標の推移、利用量の推移を確認します。問題があれば迅速に対応します。
利用状況の把握として、誰がどのくらいの頻度で利用しているかを分析します。利用が少ないユーザーグループがあれば、何が障壁になっているかを調査し、追加のサポートを行います。
フィードバックの収集として、ユーザーからの声を積極的に集めます。「使いにくい点」「期待と違った点」「良かった点」を収集し、改善に反映します。これはReinforcement（強化）の一環でもあり、「自分たちの声が反映される」という実感が、継続的な利用意欲を高めます。
成功事例の共有として、「このタスクがこれだけ効率化された」「このような使い方が効果的だった」といった事例を収集し、組織内で共有します。成功事例は、まだ利用を始めていないユーザーのDesireを高め、利用中のユーザーのReinforcement（強化）にもなります。
フェーズ6: 運用・保守
なぜ運用が重要か
AIエージェントは「デプロイしたら終わり」ではありません。むしろ、デプロイしてからが本番です。LLMの挙動は時間とともに変化する可能性があり（APIプロバイダーがモデルを更新するため）、ユーザーの利用パターンも変化します。また、業務環境の変化（新しい規程の追加、組織変更など）に応じて、エージェントの知識も更新が必要です。継続的な監視と改善なしには、エージェントの価値は徐々に低下していきます。
監視の設計
開発フェーズで構築した監視基盤を使って、エージェントの動作を継続的に監視します。産総研ガイドラインの品質特性に基づいて、監視項目を設定します。
性能監視では、レスポンスタイム、スループット、エラー率を監視し、閾値を超えた場合にアラートを発報します。特にLLM APIの呼び出し時間は外部要因で変動するため、傾向を継続的に追跡します。
品質監視では、エージェントの回答品質を継続的にモニタリングします。ユーザーからの評価（thumbs up/downなど）を収集する、定期的にサンプリングして人間がレビューする、自動評価を定期実行する、といった方法を組み合わせます。品質の低下傾向を早期に検知することで、ユーザーからのクレームが発生する前に対処できます。
セキュリティ監視では、不正なアクセスパターン、プロンプトインジェクションの試行、機密情報の漏洩の兆候を監視します。AIエージェントは新しい攻撃ベクトルを持つため、従来のセキュリティ監視に加えて、AI固有の脅威パターンを監視する必要があります。
コスト監視では、LLM APIの利用コストを監視します。想定外の利用増加や、非効率な呼び出しパターンによるコスト増を検知します。コストの急増は、システムの異常を示すシグナルである可能性もあります。
利用状況の分析では、どの部門が、どのようなタスクで、どの程度の頻度でエージェントを利用しているかを分析します。利用が伸びない部門があれば、何が障壁になっているかを調査し、追加のサポートや機能改善を検討します。
診断的アプローチによる品質改善
運用中に「精度が低い」「使いにくい」といったフィードバックを受けることがあります。しかし、このような漠然としたフィードバックをそのまま受け取っても、効果的な改善にはつながりません。医師が「体調が悪い」という訴えから診断を進めるように、課題を分解して根本原因を特定する診断的アプローチが必要です。
RAGを使用するエージェントの場合、「精度が低い」という課題は大きく「検索（Retrieval）の問題」と「生成（Generation）の問題」に分解できます。
検索の問題とは、そもそも関連性の高い情報が検索結果に含まれていないケースです。原因としては、必要な情報がナレッジベースに存在しない、情報は存在するが古い・不正確、チャンキング戦略が不適切で情報が分断されている、埋め込みモデルがドメインの用語を適切に捉えていない、などが考えられます。
生成の問題とは、検索された情報は正しいが、それを基にした回答が不適切なケースです。原因としては、LLMが検索結果を正しく解釈できていない、ユーザーの質問意図を汲み取れていない、検索結果にない情報を「作り出して」しまう（ハルシネーション）、回答のトーンや詳細度がユーザーの期待と合っていない、などが考えられます。
この切り分けを行うためには、問題が発生した際に「検索された情報は適切だったか」と「その情報を基にした生成は適切だったか」を個別に評価する仕組みが必要です。トレーシングを活用し、検索結果と最終回答を紐づけて記録することで、後から分析が可能になります。
RAG品質評価のメトリクス
RAGを使用するエージェントの品質を定量的に評価するためのメトリクスを紹介します。
検索品質のメトリクスとして、Precision@k（上位k件の「当たり率」：検索結果のうち実際に関連性のあるものの割合）、Recall@k（上位k件の「取りこぼし率の逆」：関連性のある情報のうち検索結果に含まれている割合）、MRR（Mean Reciprocal Rank）（「最初の正解の出現順位」：関連する結果が何番目に出現するかの平均の逆数）、Contextual Relevancy（検索されたコンテキストが質問にどの程度関連しているか）があります。
生成品質のメトリクスとして、Faithfulness（忠実性）（生成された回答が検索されたコンテキストに基づいているか、ハルシネーションがないか）、Groundedness（根拠の明確さ）（回答の各主張がソース文書に根拠を持っているか）、Answer Relevancy（回答の関連性）（生成された回答がユーザーの質問に適切に答えているか）があります。
エンドツーエンドのメトリクスとして、Answer Correctness（正確性）（最終的な回答が事実として正確か）、Response Latency（応答時間）（ユーザーの質問から回答までの時間）、User Satisfaction（ユーザー満足度）（thumbs up/downや評価スコア）があります。
これらのメトリクスを継続的に収集・可視化することで、品質の傾向を把握し、問題が発生した場合に「検索を改善すべきか」「生成を改善すべきか」の判断材料を得られます。RAGASやDeepEvalなどのオープンソースフレームワークを活用することで、これらのメトリクスの自動計測が可能です。
仮説駆動型の改善サイクル
品質改善を効果的に進めるためには、仮説駆動型のアプローチを推奨します。「なんとなく良くない」という感覚に基づいて改善施策を打つのではなく、「なぜ良くないのか」の仮説を立て、データで検証し、効果を測定するサイクルを回します。
Phase 1: 仮説構築では、品質問題が報告された際に、その根本原因について仮説を立てます。たとえば、「営業部門で精度が低いと言われている」という報告に対して、「営業部門は商談議事録の要約にRAGを使っており、議事録特有の話し言葉や略語がチャンキングで分断されているのではないか」という仮説を立てます。仮説構築のためには、利用部門へのヒアリング、実際のクエリと回答のサンプル分析、メトリクスの部門別・ユースケース別の分解が有効です。
Phase 2: 仮説検証では、立てた仮説をデータで検証します。たとえば、営業部門の利用ログを分析し、「検索品質のメトリクスが低いのか」「生成品質のメトリクスが低いのか」を確認します。検索品質が低ければ「検索の問題」という仮説が支持され、生成品質が低ければ「生成の問題」という仮説が支持されます。
Phase 3: 改善施策の実施では、検証された仮説に基づいて改善施策を実施します。検索の問題であれば、チャンキング戦略の見直し、埋め込みモデルの変更、ナレッジベースの拡充などを検討します。生成の問題であれば、プロンプトの改善、Few-shot例の追加、モデルの変更などを検討します。
Phase 4: 効果測定では、改善施策の効果を定量的に測定します。施策実施前後でメトリクスがどう変化したかを確認し、仮説が正しかったか、施策が効果的だったかを評価します。効果が不十分であれば、仮説を見直すか、別の施策を検討します。
ユースケース・ブループリントの作成
運用が安定してきたら、エージェントの利用実態を可視化した「ユースケース・ブループリント」を作成することを推奨します。これは、誰が、何を、どのように利用しているかを整理した「RAG利用設計図」であり、今後の改善の羅針盤となります。
ブループリントには以下の要素を含めます。主要ユースケースマップとして、どの部門がどのようなタスクでエージェントを最も活用しているかをマッピングします。課題の構造分析として、各ユースケースにおける課題が「検索」起因か「生成」起因かを整理します。ユーザーペルソナとして、利用頻度や目的に基づいて主要なユーザータイプを定義します。改善ロードマップとして、分析結果に基づいてインパクトの大きい改善施策を優先順位付けします。
このブループリントを定期的に更新することで、エージェントの改善を「場当たり的」ではなく「戦略的」に進められます。
インシデント対応
問題が発生した場合の対応手順を整備しておきます。インシデントの検知、影響範囲の特定、原因の調査、対策の実施、再発防止策の検討という一連の流れを、責任者と手順を明確にして定義します。
AIエージェント固有のインシデントとして、「不適切な回答をした」「ガードレールをすり抜けた」「意図しない操作を実行した」「機密情報が漏洩した」といった事象が考えられます。これらについても、対応手順と報告先を定めておきます。特に、ハルシネーションによる誤情報の提供は、業務判断に影響を与える可能性があるため、重大なインシデントとして扱う基準を明確にしておきます。
継続的な改善
運用データを分析し、エージェントを継続的に改善します。
評価の定期実行では、開発フェーズで作成した評価データセットを定期的（週次または月次）に実行し、品質が維持されていることを確認します。LLMのAPIプロバイダーがモデルを更新した際には、必ず評価を実行して品質への影響を確認します。モデル更新により品質が向上することもあれば、予期せず低下することもあります。
評価データセットの拡充では、運用中に発見された問題事例を評価データセットに追加します。「この質問に対してこの回答は不適切だった」という事例を蓄積することで、同じ問題の再発を防止できます。また、新しいユースケースが発見された場合も、それに対応する評価ケースを追加します。
プロンプトの改善では、品質監視の結果を踏まえて、プロンプトを改善します。ただし、プロンプトの変更は予期しない副作用を生む可能性があるため、変更後は必ず評価を実行して品質への影響を確認します。プロンプトはコードと同様にバージョン管理し、変更履歴を追跡できるようにしておきます。
ナレッジベースの更新では、RAGで参照するデータを最新の状態に保ちます。業務規程の改訂、新しいマニュアルの追加、古い情報の削除などを定期的に行います。産総研ガイドラインのデータ品質の観点（最新性、正確性、一貫性）を維持することが、エージェントの回答品質を維持することにつながります。
定期的なレビュー
月次や四半期ごとに、エージェントの運用状況をレビューします。
KPIの達成状況として、要件定義で設定した業務KPI（対応時間の短縮率、人手対応率の削減など）が達成されているかを確認します。
品質指標の推移として、各種メトリクス（検索品質、生成品質、ユーザー満足度）の推移を確認し、低下傾向があれば原因を調査します。
コストの推移として、LLM API利用コストが予算内に収まっているか、コスト効率（1件あたりのコスト）が改善しているかを確認します。
インシデントの発生状況として、発生したインシデントの件数、種類、対応状況を確認し、再発防止策が機能しているかを評価します。
ユーザーからのフィードバックとして、収集したフィードバックを整理し、改善要望の優先順位付けを行います。
改善計画の策定として、レビュー結果に基づいて次期の改善計画を策定します。仮説駆動型のアプローチで、優先度の高い課題から取り組みます。
生産性向上効果の測定
エージェントの投資対効果を継続的に測定し、ステークホルダーに報告します。「エージェントがなかった場合と比較して、どの程度の時間が節約されたか」を定量化することで、継続的な投資の正当化と、さらなる改善への予算確保が可能になります。
測定方法としては、ユーザーアンケートで「エージェントがなかった場合、同じ業務にどの程度の時間がかかったか」を聞く方法があります。また、エージェント導入前後の業務時間を比較する方法、エージェントの利用量と業務量の相関を分析する方法なども有効です。
これらのデータは、ADKARのReinforcement（強化）にも活用できます。「このエージェントにより、全社で月間〇〇時間の業務が効率化された」という成果を共有することで、利用の継続と拡大を促進できます。
おわりに
本フレームワークは、AIエージェントを「特別なもの」としてではなく、「業務で使うソフトウェアの一種」として捉え、従来のシステム開発で培われた知見を土台に、AIエージェント固有の考慮事項を追加する構成を取りました。
特に、産総研の「生成AI品質マネジメントガイドライン」の品質体系を参照することで、LLM利用AIシステムに求められる品質特性を体系的に整理し、要件定義・設計・テストの各フェーズで考慮すべき観点を明確にしました。また、Clean Architectureの原則を適用し、ビジネスロジックと技術的詳細を分離することで、将来の変更に柔軟に対応できる構造を目指しています。Agile開発との組み合わせでは、「何を固定し、何を柔軟にするか」を明確にすることで、「Agileの柔軟性」を誤解なく活用できる指針を示しました。
本フレームワークでは、移行・デプロイフェーズと運用・保守フェーズにも重点を置いています。AIエージェントの成功は、技術的な完成度だけでなく、ユーザーに実際に使ってもらえるかどうかにかかっています。ADKARモデルに基づく変更管理により、ユーザー一人ひとりの行動変容を支援することが重要です。また、運用フェーズでは「精度が低い」といった漠然としたフィードバックを「検索」と「生成」に分解して診断する仮説駆動型のアプローチにより、効果的な改善を継続的に行うことができます。
AIエージェント開発で最も重要なのは、「まず簡単に作り、動かし、評価し、改善する」というサイクルを回すことです。完璧な設計を追求して着手が遅れるより、最小限の機能でまず動くものを作り、実際の挙動を見ながら改善していく方が、結果として品質の高いシステムに到達できます。
ただし、「最小限」と「雑」は異なります。ここで言う「最小限（MVP: Minimum Viable Product）」は機能の最小化であり、安全・監査・可観測性は最小限でも必須要件です。言い換えれば、「MVS（Minimum Viable Safety）」—セキュリティ、ガードレール、監視の仕組み—は、最初から組み込んでおく必要があります。これらを後付けにすると、抜け漏れが発生しやすく、また、問題が発生したときに原因を特定できなくなります。そして、非機能要件やドメインモデルの核といった「固定すべき要素」は、Agile開発であっても早期に決定し、安易に変更しない規律を持つことが重要です。
本フレームワークが、皆様のAIエージェント開発の一助となれば幸いです。
参考文献
公式ガイドライン
産総研（AIST）「生成AI品質マネジメントガイドライン 第1版」（2025年5月）は、LLM利用AIシステムが満たすべき品質特性を体系的に整理した国内初の包括的ガイドラインです。本フレームワークの品質設計・評価の基盤として参照しています。
OpenAI「A Practical Guide to Building Agents」（2025年）は、エージェント構築の実践的な指針を提供しています。モデルの選定、ツールの設計、ガードレールの実装について、具体的な推奨事項が記載されています。
Anthropic「Building Effective Agents」（2024年）は、「必要以上に複雑にしない」という原則を強調し、段階的にエージェントを構築するアプローチを推奨しています。
アーキテクチャ・設計
Robert C. Martin「Clean Architecture: A Craftsman's Guide to Software Structure and Design」（2017年）は、ソフトウェアアーキテクチャの原則を体系的に解説しています。依存関係の方向、層の分離、SOLID原則について、具体例を交えて説明しています。
Martin Fowler「Is Design Dead?」（2004年）は、Agile開発における設計の役割について論じた重要な記事です。
Agile開発
James O. Coplien & Gertrud Bjørnvig「Lean Architecture: for Agile Software Development」（2010年）は、AgileとLean志向のソフトウェア設計について解説しています。
SAFe（Scaled Agile Framework）の「Agile Architecture」ガイドラインは、大規模Agile開発におけるアーキテクチャの役割について指針を示しています。
変更管理
Prosci「The ADKAR Model」は、個人の変革を支援するためのフレームワークです。Awareness、Desire、Knowledge、Ability、Reinforcementの5要素で構成され、組織変革プロジェクトにおいて広く活用されています。Jeff Hiatt氏が700以上の組織の変革パターンを研究して開発しました。
Jeff Hiatt「ADKAR: A Model for Change in Business, Government and our Community」（2006年）は、ADKARモデルの詳細と適用方法を解説した原典です。
RAG評価・品質管理
Shahul Es et al.「RAGAS: Automated Evaluation of Retrieval Augmented Generation」（2023年）は、RAGシステムの自動評価フレームワークを提案した論文です。Faithfulness、Answer Relevancy、Context Precisionなどのメトリクスを定義しています。
Pinecone「RAG Evaluation: Don't let customers tell you first」は、RAG評価の実践的なガイドで、各種評価フレームワーク（RAGAS、Arize、TruLens等）の比較と選定指針を提供しています。
Evidently AI「A complete guide to RAG evaluation」は、RAG評価のベストプラクティスを包括的にまとめたガイドで、開発時の評価から本番環境での継続的モニタリングまでをカバーしています。
AI支援開発
Andrej Karpathy氏は2025年2月にX（旧Twitter）で「Vibe Coding」という概念を提唱しました。LLMを活用して自然言語からコードを生成し、「バイブスに身を任せてコードの存在を忘れる」開発スタイルを指します。プロトタイピングには有効ですが、本番システムへの無批判な適用にはリスクが伴います。
Simon Willison「Not all AI-assisted programming is vibe coding」（2025年3月）は、Vibe Codingと責任あるAI支援開発の違いを明確に区別した重要な記事です。「LLMがコードを書き、あなたがレビュー・テストし、説明できるなら、それはソフトウェア開発」と指摘しています。
METR（2025年）は、経験豊富な開発者がAIツールを使用した際の生産性影響に関する調査を実施しました。主観的には速くなったと感じながら実測では生産性が低下するという結果が報道されています。
InfoWorld「Is vibe coding the new gateway to technical debt?」（2025年12月）およびTechStartups「The Vibe Coding Delusion」（2025年12月）は、Vibe Codingの落とし穴と技術的負債の蓄積について、実例を交えて警鐘を鳴らしています。GitClearはAI生成コードにおける重複コードの増加傾向について調査を公開しています。
プロトコル仕様
MCP（Model Context Protocol）は、Anthropicが2024年頃に提唱・公開したツール接続の標準化プロトコルです。公式サイト（modelcontextprotocol.io）で仕様が公開されています。
A2A（Agent-to-Agent Protocol）は、Googleが2025年4月に発表したエージェント間連携の標準化プロトコルです。発表後、Linux Foundationに移管され、オープンな形で開発が進められています。
業界調査
LangChain「State of Agent Engineering」（2025年末実施、1,300名以上回答）は、エージェント開発の現状と課題に関する調査です。57%が本番環境でエージェントを運用中、89%がObservabilityを実装済み、52%が評価を実装済みという結果が報告されています。
本記事は2026年1月時点の情報に基づいています。AIエージェント技術は急速に進化しているため、最新情報については各ベンダーの公式ドキュメントも参照してください。
