「やりたいこと」と「どう動かすか」の間にある溝
Definition で「修繕依頼から設備と症状を読み取り、緊急度を判定したい」と決まりました。でも、この一文では AI は動きません。どんな指示を与えるのか、出力をどんな形で受け取るのか、どんなデータを渡してはいけないのか。これを具体的に決めるのが Design です。設計は3つの領域に分けて考えます。試験では「この設計論点はどの領域か」を判別させる問題が出ます。
| 領域 | 問い |
|---|---|
| コンテキスト設計 | AI にどう指示するか |
| I/O 設計 | AI とどんな形式でやり取りするか |
| セキュリティ設計 | AI に何を見せて、何を出させないか |
領域1 コンテキスト設計：AI にどう指示するか
第4章のコンテキストエンジニアリングが「AI に渡す情報をどう考えるか」の原則論だったのに対し、ここでは「システムプロンプトに何を書くか」という具体的な手法に踏み込みます。
システムプロンプトは、AI の役割・前提・制約を定める最上位の指示です。「あなたは賃貸物件の修繕依頼の一次受付担当です。入居者の依頼文と写真から、設備の種類・症状・入居者が確認済みの事項を抽出し、緊急度を即日・3日以内・通常の3段階で判定してください。判定の根拠を項目別に明記してください。入居者の国籍・年齢・契約形態は判定に使ってはいけません」のように書きます。「根拠を項目別に」はペルソナ A の要求を、「属性を使わない」は制約条件を、プロンプトで実現しています。
出力の質を上げる代表的な技法が2つあります。
Few-shot は、入力例と出力例の組を数件プロンプトに含めて、期待する形式や判断の傾向を示す手法です。効果は高いのですが、どの例を選ぶかで結果が大きく変わります。「即日」が明らかな例だけを並べると、即日か3日以内かが微妙な依頼の判定が不安定になります。明確な緊急例、明確な通常例、判断が分かれる境界例をバランスよく入れることが重要です。
この弱点を補う実務的な方法が 「例からルールを抽出する」 やり方です。例をそのまま並べるのではなく、まず AI にベテラン担当者が判定した依頼を十数件分析させて「どういう基準で判断しているか」を言葉にさせます。それを人（ベテラン担当者）が確認し、「冬場の給湯器停止は高齢者世帯でなくても即日にする」「水漏れは階下への影響があれば症状が軽くても即日」といった修正を加え、整理されたルールをシステムプロンプトに組み込みます。個別の例に依存しなくなるので、未知のパターンに強くなります。Few-shot の例は補助として3件程度（緊急・通常・境界）を添える形です。
Chain-of-Thought は、AI に考える手順を段階的に踏ませる手法です。「まず設備の種類を特定し、次に症状を抽出し、入居者が確認済みの事項を除外し、生活への影響と二次被害の可能性から緊急度を決める」と順序を明示します。人が複雑な問題を暗算より紙に書いて解く方が正確なのと同じ原理です。ただし段階が増えるほどトークンが増えるので、複数の判断を組み合わせる処理に限って使い、コストと精度のバランスを取ります。
領域2 I/O 設計：出力を機械が読める形にする
AI が「給湯器の故障の可能性が高く、お湯が使えないので早めの対応がよいと思います。業者は A 社か B 社が…」と文章で返してきたらどうなるでしょう。人が読むには十分ですが、業者の手配システムに緊急度を自動登録しようとすると、文章から「即日」にあたる言葉を探す処理が要ります。次の依頼で「できれば早め」と返されたら、どの段階に入れるかでシステムが止まります。
だから出力は あらかじめ決めた形式 で返させます。代表が JSON で、「urgency: 即日」「equipment: 給湯器」のように項目名と値の対応で書くデータ形式です。
スキーマは JSON の設計図です。どの項目を含めるか、各項目は文字列か数値か真偽値か、どれが必須か、値の範囲はどこまで許すか（緊急度は3つの値のいずれか、など）を事前に決めます。スキーマがあれば、出力が期待どおりの形かを自動で確認できます。この確認を バリデーションと呼び、必須項目が欠けている、決めた3つ以外の値が入っている、といった不整合が見つかったら、AI に再生成を求めるか人に引き継ぐ、という対応まで設計しておきます。
修繕依頼の出力例では、症状ごとの読み取り結果を配列にして根拠を項目別に示し、AI の確信度（confidence）のフィールドを設けて低いときは自動で担当者の確認に回し、公平性チェックの合否フラグを持たせて後続の処理で参照できるようにします。
領域3 セキュリティ設計：入口と出口の二重の制御
セキュリティ設計は、「AI に何を見せるか」と「AI に何を出させるか」の両方を管理します。
- アクセス制御（入口）: AI が参照できる情報の範囲を制限する。依頼を渡す前に、判定に不要な入居者の氏名・国籍・年齢・契約形態をマスキングする。プロンプトで「使うな」と指示するだけでは完全に排除できないので、そもそも見せない設計にする。これがセキュリティ・バイ・デザインの考え方です。
- ガードレール（出口）: AI の出力に制限を設ける。「高齢の方なので〜」「外国籍の入居者のため〜」のような属性に基づく表現が出力に含まれていたら検知し、遮断して再生成を求める。
公平性の確保は、入口と出口の両方で対策します。試験では「プロンプトの指示のみ」「JSON に属性のフィールドを追加」「属性に基づく判定の『正しい例』を Few-shot に入れる」が誤答として並びます。設計時に入れて終わりではなく、運用後も同じ症状で属性だけ変えた模擬依頼を定期的に入力し、判定が変わらないかを監視し続けます。
ストラテジストは Design で何をするか
3領域の技術的な実装はアーキテクトの仕事です。ストラテジストの役割は、Definition で決めた業務要件が設計に正しく反映されているかを確認することです。「ペルソナ B の『症状の詳細を添えてほしい』は I/O 設計の JSON スキーマに入っているか」「制約条件の属性の不使用はアクセス制御に落とされているか」をレビューします。
試験で問われる観点
- 依頼を送る前に氏名・属性をマスキングする設計は、セキュリティ設計（アクセス制御）。
- 「要件定義書に精度 90% 以上と記載した」は Definition、「出力を JSON で構造化しスキーマを定義した」は Design。境界は「業務要件の文書化か、技術設計か」。
- 属性に基づく判定コメントを防ぐ対策の組み合わせ（入口でマスキング＋出口で自動検出してブロック）。
- Few-shot の例は緊急・通常・境界をバランスよく。偏った例は精度を下げる。
- Chain-of-Thought は段階的に考えさせる手法。トークンが増えるので複雑な判断に限って使う。
- ストラテジストは実装ではなく、要件が設計に反映されているかの確認を担う。