novel-jp/learn-ie-casestudy

/learn-ie-casestudy — ケーススタディ（03-04）

実際の事例から Intent Engineering の重要性を学ぶ演習です。

所要時間: 約 45 分 前提: /learn-ie-analyze（03-01）完了済み スキル対応: Intent Engineering（目的と判断基準）

Intent Engineering とは: AI に「何を最適化すべきか」「何を犠牲にしてはいけないか」という判断基準を明示的に伝える技術です。03-01 で DR 分析を通じて学んだ「なぜ」の記録の延長にあります。

---

前提チェック

03-01（/learn-ie-analyze）が完了済みか確認する。未完了の場合:

「この演習は 03-01 DR 分析の知識を前提としています。
先に /learn-ie-analyze を完了してから戻ってきてください。」

未完了なら ここで終了 する。

タスク確認・開始

1. list_tasks(projectId) で学習プロジェクトのタスク一覧を取得する
2. 本演習に対応するタスクがあれば start_work(taskId) で開始する
3. タスクがなければ upsert_task で作成してから start_work する

---

Step 1: Klarna の事例を読み解く

以下の事例を提示する:

「Klarna は 2024 年に AI カスタマーサポートを大規模導入しました。
当初は成功と報じられましたが、後に顧客満足度の低下が明らかになりました。

AI は『解決時間の短縮』に最適化されましたが、
顧客が求めていた『寄り添い』や『理解されている感覚』を提供できませんでした。

※ この事例は 2024 年の報道を基に構成しています。

質問: なぜこうなったと思いますか？
AI の能力不足でしょうか、それとも別の原因がありますか？
あなたの考えを聞かせてください。」

受講者に回答を求め、回答が得られてから次に進む。

回答へのフィードバック

受講者の回答を受け取ったら、以下の観点でフィードバックする:

• 「AI の限界」に言及していたら → 「AI の能力の問題ではなく、指示の問題です」と方向修正
• 「指標が悪かった」に言及していたら → 「良い視点です。では何の指標を使うべきだったでしょうか？」と深掘り
• 「共感が足りない」に言及していたら → 「正解に近いです。ではどうすれば AI に共感を指示できたでしょうか？」と次へつなげる

フィードバック後、以下の解説を提示する:

「原因は Intent の欠落です:

- コンテキスト（FAQ データ、顧客情報、過去の問い合わせ履歴）は完璧だった
- しかしインテント（『顧客に寄り添う』『満足度を重視する』）が定義されていなかった
- AI は与えられた指標（解決時間）を最大化し、定義されていない指標（共感、満足度）を最小化した

これは AI の限界ではなく、Intent Engineering の失敗です。
AI は『最適化しろ』と言われたものを最適化します。
何を最適化すべきか伝えなければ、測りやすい指標だけに集中します。」

---

Step 2: 自社への応用

対象プロジェクトの選定

「次に、この教訓を自分のプロジェクトに当てはめてみましょう。

以下のいずれかを対象にしてください:
1. 02-02 で作成したミニプロジェクト
2. 現在関わっている実務プロジェクト
3. どちらもない場合は、以下のシナリオを使ってください:

   『社内向けタスク管理ツールの開発。チーム 5 名、リリースまで 3 ヶ月。
   ユーザーは非エンジニアの営業部門 30 名。既存の Excel 管理から移行する。』

どれを使うか教えてください。」

受講者に選択を求め、回答が得られてから次に進む。

応用の問い

対象プロジェクトが決まったら、以下の質問を提示する:

「そのプロジェクトで Klarna と同じことが起きるとしたら？
以下の 3 つの質問に、それぞれ具体的に答えてください。」

| 質問 | 考えるポイント | | -------------------------------- | ---------------------------------------------- | | 何に最適化されるべきか | ユーザー体験？開発速度？コスト？安全性？ | | 何が犠牲にされてはいけないか | セキュリティ？アクセシビリティ？データ整合性？ | | それを AI にどう伝えるか | CLAUDE.md? DR? タスクの description? |

受講者に 3 つの回答を求め、回答が得られてから次に進む。

回答へのフィードバックと深掘り

受講者の回答を受け取ったら:

1. 各回答が具体的か確認する。「ユーザー体験」のような抽象的な回答には「ユーザー体験の中でも特に何ですか？初回の学習コスト？日常の操作速度？エラー時の安心感？」と深掘りする
2. 3 つ目の「AI にどう伝えるか」について、以下の比較表を提示する:

| 手段 | 適切な用途 | 永続性 | | ---------------------- | ------------------------------ | ------------------------ | | CLAUDE.md | プロジェクト全体の価値観・方針 | 高（常に参照される） | | DR | 個別の意思決定とその理由 | 高（変更履歴として残る） | | タスク description | タスク固有の判断基準 | 中（タスク完了まで） | | プロンプト | 一時的な指示 | 低（セッション限り） |

3. 深掘りの質問を投げる:

「あなたが挙げた優先順位で、判断が分かれる具体的な場面を 1 つ挙げてください。
たとえば『セキュリティを最重視する』なら、セキュリティと開発速度が衝突する場面は？」

受講者に回答を求め、回答が得られてから次に進む。

---

Step 3: インテントの言語化

なぜトレードオフは不可避か

「ここまでで『何を優先するか』を考えてもらいました。
でも、なぜ優先順位が必要なのでしょうか？ 全部やればいいのでは？

現実にはリソース（時間・人・お金）が有限です。

例: 締切まで 2 日。セキュリティ監査と UI 改善、どちらを先にやる？
両方やる時間はない — これがトレードオフです。

AI も同じです。『セキュリティもUXも速度も全部大事』と伝えると、
AI は自分の判断で優先順位を決めます。それはあなたの意図と一致しないかもしれません。

『全部大事』は何も言っていないのと同じ — 優先順位をつけることが Intent Engineering の本質です。」

インテント宣言を書く

「では、あなたのプロジェクトのインテント宣言を書いてください。

フォーマット:
『このプロジェクトは [X] を最重視し、[Y] のためなら [Z] を犠牲にしてもよい』

例:
- 『このプロジェクトはデータ整合性を最重視し、安全性のためなら開発速度を犠牲にしてもよい』
- 『このプロジェクトはユーザーの第一印象を最重視し、UX のためなら機能数を犠牲にしてもよい』
- 『このプロジェクトは学習コストの低さを最重視し、チーム生産性のためなら最新技術の採用を犠牲にしてもよい』

1〜3 文で書いてみてください。」

受講者に回答を求め、回答が得られてから次に進む。

フィードバックと記録

書かれたインテント宣言について:

• トレードオフが明確か確認する（「X を重視」だけでなく「Z を犠牲にしてもよい」まで書けているか）
• 「全部大事」になっていたら → 「2 つに絞るとしたら？」と絞り込みを促す
• 具体的で良い宣言が書けていたら → 明確に褒める

フィードバック後、インテント宣言を ProjSight に記録する:

「良いインテント宣言が書けました。せっかくなので記録に残しましょう。」

upsert_task(taskId, notes) で、タスクの notes に以下の形式で記録する:

## インテント宣言（03-04 演習成果）

[受講者が書いたインテント宣言をここに記録]

### 対象プロジェクト

[選択したプロジェクト名]

オプション: 受講者が learn-workspace を持っている場合、「この宣言を learn-workspace の CLAUDE.md にも追記しますか？ プロジェクト全体の方針として AI が常に参照するようになります」と提案する。希望があれば追記を支援する。

---

Step 4: 振り返り

「インテントを明文化することで、AI の自律的な判断に方向性を与えられます。

今日のポイント:
- AI は指示されたことを最適化する。指示されていないことは無視する
- 『全部大事』は何も言っていないのと同じ — 優先順位が Intent
- CLAUDE.md にインテント宣言を書くと、全ての作業に一貫性が生まれる
- Klarna の教訓: コンテキストだけでなく、価値観も伝える必要がある

この演習で書いたインテント宣言は、今後の演習や実務でも活用できます。
プロジェクトの状況が変われば、インテントも更新してください。」

受講者のタスクを complete_work(taskId) で完了にする。