AI適用可否と委任レベルの設計
生み出したい価値と業務変化から、AI・人間・既存システムの役割を逆算する。誤りの影響や検証可能性を踏まえ、AIを使わない選択も含む最小の委任範囲を決める。
最終更新：
AI設計
与えられた業務要求を、AI・人間・既存システムの役割、必要な情報、要件・方式、検証・運用へ具体化する設計領域です。
目次
- 価値から始める
- AIを業務・システムへ組み込むための設計領域
- 価値・AI適用判断
- 業務全体の効果
- 責任境界・Human in the Loop
- Knowledge / Context設計
- AI評価設計
- AIアーキテクチャ・既存システム統合
- Agent / Tool / Workflow設計
- AIセキュリティ・権限制御
- AI導入・定着・改善
- 監視・再評価・終了
- 設計領域ごとの記事
- AI適用判断
- AI適用可否と委任レベルの設計
- 責任境界・制御
- AI出力の責任境界とHITL
- ハルシネーションの多層制御設計
- なぜ回答範囲を制限した方がよいのか
- ガードレールの数学的説明
- ナレッジ / コンテキスト
- Instruction・Knowledge・Evidenceの責務分離
- 人向け資料とAI向け資料の分離設計
- プロンプト設計の基本構造
- QA行動制約Knowledge
- プロンプト設計の失敗モード
- 評価・ヒューマンレビュー
- AI評価データセットと回帰評価設計
- QAチャット評価設計思想
- コード生成AIの評価と採用設計
- システムアーキテクチャ
- AI業務システムの参照アーキテクチャ
- AI間インターフェースとしてのプロンプト
- 生成AIセキュリティと脅威モデリング
- AIコスト・Latency・モデルルーティング設計
- ソフトウェア開発
- AIを開発工程に組み込む
- なぜAIは新規コードよりコード保守に強いのか
- 複数AIの役割分担と工程設計
- ライフサイクル・運用
- AIシステムのオブザーバビリティとSLO設計
- AIシステムの変更・再評価設計
- QAチャット運用思想
AI技術の導入を目的にせず、実現したい業務変化からAI・人間・既存システムの役割を決めます。AIを使わない判断も、AI設計の一部です。
目的・業務目標・システム化の範囲を決める企画と、その要求を要件・方式へ具体化する設計を区別します。技術検証の結果から企画へ戻る場合も、判断の対象を分けます。
価値から始める
- 価値・適用判断
- 責任・情報・評価
- 構成・実行・権限
- 運用・改善
- 再評価・縮小・終了
AIを業務・システムへ組み込むための設計領域
番号は読む順の目安です。実装の固定順ではなく、評価や運用で分かったことを前の判断へ戻しながら設計します。各項目から設計の説明、または領域別の記事へ進めます。
01 · 設計原則
価値・AI適用判断
誰にどんな価値を生むかから始め、AIを使わない選択も含めて、必要な最小の委任範囲を決めます。
02 · 業務設計
業務全体の効果
生成の速さだけでなく、確認・説明・手戻り・合意まで含めて、工数と完了までの時間を評価します。
03 · 設計ガイド
責任境界・Human in the Loop
AIの候補を誰が確認・採用・承認するかを決め、人間が判断できない場合の停止と引き継ぎを設計します。
04 · 領域別の記事
Knowledge / Context設計
指示、継続して使う知識、今回の根拠を分け、対象・版・権限に合った情報をAIへ渡します。
05 · 領域別の記事
AI評価設計
回答やコードの検証、採用基準、回帰テスト、人間レビューを分け、品質と業務価値を評価します。
06 · 参照アーキテクチャ
AIアーキテクチャ・既存システム統合
AIによる候補生成、システムによる検証、人間の承認、既存システムの実行を分離し、一つの業務システムへつなぎます。
07 · 設計ガイド
Agent / Tool / Workflow設計
単一AIで足りるかを判断し、必要な情報・道具・権限・状態を定義します。既知の制御はプログラムへ置き、動的な探索だけをAIへ任せます。
09 · 実務ガイド
AI導入・定着・改善
担当者、例外対応、教育、業務成果を確認し、日々の運用結果を委任範囲と仕事の改善へ戻します。
10 · 領域別の記事
監視・再評価・終了
品質・費用・異常を観測し、変更時に評価し直します。必要なら範囲縮小、統合、停止、終了を選び、仕事を引き継ぎます。
設計領域ごとの記事
上の設計領域から読む内容を選んだ後、関連する原則や詳しい手順を領域ごとに確認できます。
AI適用判断
AIでできるかだけでなく、任せるべきかを判断します。影響・確認のしやすさ・戻せるかから任せ方を決めます。
責任境界・制御
AIの提案を誰が確認し、誰が実行を承認するかを決めます。責任の境界と、危険な処理を止めるGuardrailを設計します。
AI出力の責任境界とHITL
AIが答えや作業案を出した後、誰が確認し、採用し、実行を承認するかを決めます。人への引き継ぎ条件・根拠・記録まで含めてHuman in the Loopを設計します。
ハルシネーションの多層制御設計
誤答の生成、見逃し、採用・実行を分け、業務への流出リスクを多層で制御する。根拠取得・検証・回答拒否・人への移管・実行権限を組み合わせた設計を示す。
なぜ回答範囲を制限した方がよいのか
AIが答えてよい質問と、人へ渡すべき質問の範囲を決めます。対象・版・根拠・入力条件を明示し、回答・拒否・引き継ぎの品質を継続して測ります。
ガードレールの数学的説明
AIへ「してはいけない」と伝えることと、システムが実際に止めることは異なります。指示による誘導、生成時の制約、検証、実行認可を分け、Guardrailの限界を説明します。
ナレッジ / コンテキスト
AIへ何を指示し、何を根拠に渡し、その場の条件をどう伝えるかを分けます。ナレッジ / コンテキストの役割と更新方法を設計します。
Instruction・Knowledge・Evidenceの責務分離
AIへの作業指示、継続して参照する知識、今回の回答を支える根拠を分けます。Instruction・Knowledge・Evidenceの役割を明確にし、更新や失敗原因の確認を個別に行える構成を考えます。
人向け資料とAI向け資料の分離設計
人が全体を理解する資料と、AIが根拠を検索する資料は、読み方が異なります。知識の正本は一つに保ち、版・条件・例外を共有しながら、表示と取得単位を分けて設計します。
プロンプト設計の基本構造
AIへ何を頼み、何を根拠にし、どの形で返してほしいかを分けて伝えます。Role・Task・Contextなどからプロンプトを構成し、権限や承認はシステム側の制御と区別します。
QA行動制約Knowledge
問い合わせに何を答え、何を開示せず、どこで人へ渡すかを決めます。対応規則をKnowledgeとして管理し、指示に書くだけでなく、実行時の検証・認可で業務への流出を防ぎます。
プロンプト設計の失敗モード
指示を長くしても、必要な情報が足りなかったり、指示同士が矛盾していたりすればAIは失敗します。Context不足・情報の混在・検証基準の欠如を分けて、直すべき箇所を判断します。
評価・ヒューマンレビュー
AIの答えをどこまで機械で評価し、どこから人間が判断するかを決めます。評価・ヒューマンレビューで、採用と改善の基準を設計します。
AI評価データセットと回帰評価設計
通常・曖昧・情報不足・拒否すべき入力と期待動作を評価データセットに記録する。システム全体の版管理、回帰比較、AI採点の確認、本番の失敗を評価へ戻す運用を扱う。
QAチャット評価設計思想
AIの回答が正しいかだけでなく、根拠の提示、回答を控える判断、人への引き継ぎも評価します。検索から業務効果までを分けて測り、QAの改善箇所を見つけます。
コード生成AIの評価と採用設計
AIが書いたコードを、安全に採用できる変更かどうか確認する工程を設計します。コンパイラ・テスト・静的解析・人間のレビューを組み合わせ、未確認の変更を本番へ流しません。
システムアーキテクチャ
AI・人間・既存システムをどうつなぐかを考えます。処理の流れ、権限、安全性を含むシステムアーキテクチャを設計します。
AI業務システムの参照アーキテクチャ
AIの答えをそのまま業務処理に使わず、確認・承認・実行を分ける全体構成を示します。必要情報（Context）の準備から監視までをつなぎ、誤生成が業務へ届く経路を制御します。
AI間インターフェースとしてのプロンプト
複数のAIへ仕事を渡すとき、成果物・根拠・状態を取り違えずに引き継ぐ方法を考えます。プロンプトを受け渡しの契約として捉え、情報の型・意味・権限を検証します。
生成AIセキュリティと脅威モデリング
AIが読む情報、使える権限、呼び出すツール、出力先を境界ごとに整理する。Prompt Injectionなどの脅威を想定し、影響の限定・検出・停止・復旧を設計する。
AIコスト・Latency・モデルルーティング設計
回答の速さやモデルの価格だけでなく、やり直しと人間の確認を含めて処理方法を選びます。品質・待ち時間（Latency）・リスクから、使うモデルや処理経路を評価します。
ソフトウェア開発
コードを作る速さだけでなく、安全に変更を採用できるかを考えます。開発・保守の工程へAIを組み込む方法を扱います。
AIを開発工程に組み込む
AIが受け取る入力、出力成果物、根拠、検証、停止条件、承認者を開発工程として定義する。検証済みの成果物だけを次へ渡すための契約・Gate・記録・手動経路を整理する。
なぜAIは新規コードよりコード保守に強いのか
既存コード・テスト・差分が、AIの生成条件と検証根拠になる理由を整理する。保守が常に容易とはせず、依存関係や検索コストを踏まえて調査・局所変更・検証へ分解する。
複数AIの役割分担と工程設計
複数のAIを使うとき、誰に何を渡し、どの成果物を確認して次へ進むかを決めます。Task・Context・Tool・権限を役割ごとに整理し、工程全体の品質と費用を管理します。
ライフサイクル・運用
導入後に何を監視し、変更時に何を確認し、いつ停止するかを考えます。ライフサイクル・運用として改善・移行・終了まで設計します。
AIシステムのオブザーバビリティとSLO設計
質問から検索・生成・検証・承認・実行までを記録し、誤回答の原因を追跡できる運用を考える。技術指標と品質指標を分け、SLOと異常時の対応を設計する。
AIシステムの変更・再評価設計
AIシステムを変更したとき、どこを確認し直し、問題があればどう元へ戻すかを考えます。モデル・指示・知識・権限をVersion Bundleで管理し、再評価とリリースの条件を整理します。
QAチャット運用思想
問い合わせAIを、回答して終わる道具ではなく、知識を確認・更新し続ける仕組みとして設計します。検索・回答・拒否・人への引き継ぎ・記録を、QAとKnowledgeの運用としてつなぎます。