設計図どおりに動くかを、最速で確かめる
Design でプロンプト設計書、I/O 仕様書、セキュリティ設計書ができました。Development は、これをもとに実際に動くものを作り、想定どおりに機能するかを検証する段階です。ここで区別すべき概念が4つあります。試験では、それぞれの意味と役割の違いが問われます。
プロトタイプ・PoC・MVP：似た言葉の違い
| 言葉 | 何か | 誰のためか | 確かめること |
|---|---|---|---|
| プロトタイプ | 必要最小限の機能だけを持つ試作品 | 開発・設計のメンバー | この設計で本当に動くか |
| PoC（概念実証） | 業務上・技術上、実現できると示すための検証 | 導入を判断する意思決定者 | この方法で効果が期待できるか、進む価値があるか |
| MVP | 実際の利用者に最小限の価値を届けられる状態まで作り込んだもの | 実際の業務担当者や顧客 | 最低限使える形で提供し、使われながら改善する |
プロトタイプは「動くかを確かめる試作品」、PoC は「実現可能性を確かめる検証」、MVP は「最小限でも価値を提供する実用品」です。
プロトタイプを作るときの原則は、Discovery で選んだ範囲に絞ることです。騒音相談や契約手続きまで同時に試作すると検証すべき変数が増えすぎます。設備故障の依頼に絞り、「依頼文から設備と症状を読み取り、緊急度を判定する」という中核機能が設計どおりに動くかだけを確認します。画面の完成度や、めったに起きない特殊ケースへの対応は後です。
サンドボックス：本番から隔離された練習場
サンドボックスは、本番環境から切り離した検証用の環境です。テスト用のデータを使い、プロトタイプが設計どおりに動くかを確認します。本番のデータや業務に影響を与えずに試せるのが特徴です。
似た言葉の パイロット（Step5）との違いは、段階と対象です。
- サンドボックス: 開発・検証の段階。テスト用データで、限られた関係者が隔離環境で動作確認する。
- パイロット: 本番導入の直前または初期。実データと実際の利用者で、本番に近い環境で運用上の課題を確認する。
試験では「テスト用データを使い、隔離環境で検証している」なら Development、「実データ・実ユーザー」なら Deployment のパイロット、という判別が問われます。
PoC の検証データは偏りなく用意します。たとえば過去の依頼から 40 件を選ぶなら、緊急度が明確に即日のもの 12 件、明確に通常のもの 12 件、判断が分かれる境界のもの 8 件、写真だけで文章がない・複数の設備が同時に壊れた・入居者が専門用語を誤って使っている、といった頻度は低いが判断が難しいもの 8 件、という内訳です。
Human-in-the-Loop とフィードバックループ
HITL（Human-in-the-Loop） は、AI の処理の途中に人の確認・判断・修正を組み込む仕組みです。開発段階では出力の品質がまだ安定していないので、人が内容を確認する工程が重要です。確認した結果や修正内容は、そのまま AI を改善するための材料になります。第1章の自律性レベルと合わせると、支援型では常に人の確認が入り、協働型では条件に当たる場合だけ人が介入する、という形になります。
フィードバックループは、「実行 → 結果の評価 → 改善 → 再実行」を繰り返す改善サイクル全体のことです。Definition で決めた合格基準が「このサイクルをいつ終えてよいか」の判断基準になります。
2つの違いは、HITL が「人が確認・修正する工程」に焦点を当てた概念で、フィードバックループはそれを含む改善サイクル全体を指す概念、という点です。試験では「ベテラン担当者が結果を1件ずつ確認し、誤りがあれば正しい判定を記録してプロンプト改善の根拠にした」仕組みの名前として HITL が問われます。
実際の流れを見てみます。初回の検証で、処理時間は平均 20 秒（基準 60 秒以内）、公平性テストは属性を変えても判定が不変（基準どおり）で合格。しかし設備と症状の読み取り精度は 76%（基準 90%）、緊急度の判定一致率は 70%（基準 85%）で未達。ここでフィードバックループを回します。ベテラン担当者2名が HITL として出力を確認し、「『お湯がぬるい』を故障ではなく通常と判定しているが、冬場は即日にすべき」「『蛇口』と『水栓』を別の設備として扱っている」「入居者が『元栓は確認した』と書いていても、それを読み落として元栓確認を案内している」という3つの問題を発見。季節の条件をルールに追加し、設備名の同義語リストをシステムプロンプトに足し、「入居者が確認済みと書いた事項は再案内しない」というルールを追加。再検証で 85%・79%、3回目で 91%・87% となり、すべての基準を満たしました。
Go / No-Go / Pivot：三択で判断する
PoC の結果を受けて、進め方を決めます。根拠はすべて Definition で決めた合格基準です。
- Go: 基準をすべて満たした。本番展開（Step5）へ進む。
- No-Go: 基準に届かず、フィードバックを重ねても改善しない。いまは導入を進めない。依頼フォームの項目や設備情報の登録状況など、前提条件の見直しが必要。
- Pivot: 精度は基準を満たしたが、たとえば写真の解析コストが想定を大きく上回る。対象を文章のみの依頼に限定する、軽量なモデルに切り替える、など範囲や実装方式を修正して続ける。
Development の最終判断は「成功か失敗か」の二択ではありません。そのまま進むか、いったん止めるか、方向を修正して続けるかを、基準に照らして決めます。
初回で基準に届かないのは珍しくありません。試験では、精度 76% で基準 90% に達しなかったときの次の行動として、「即時中止」「基準を 76% に引き下げて進む」「全業務に展開してデータを増やす」はすべて誤りで、「フィードバックループでプロンプトと Few-shot を改善して再検証する」が正解になります。
試験で問われる観点
- プロトタイプをワークフローツールで構築し、テスト用の依頼 40 件で検証する活動は Development & PoC。判別の決め手はテスト用データと隔離環境。
- ベテラン担当者が結果を1件ずつ確認し、誤りを記録してプロンプト改善の根拠にする仕組みは Human-in-the-Loop。フィードバックループはそれを含むサイクル全体。
- 精度が合格基準に届かなかったときの次の行動（フィードバックループで改善して再検証）。中止、基準の引き下げ、展開拡大は誤り。
- プロトタイプ・PoC・MVP の違い。サンドボックスとパイロットの違い。
- Go/No-Go/Pivot の判断根拠は Definition で決めた合格基準。