🎯

AIは知っているのに使わない — 設計タスクの "task-kickoff" プロトコルで潜在能力を引き出す

に公開
AI
設計
Claude
組織設計
engineeringmanagem
idea

はじめに

ある DB 設計の議論で、こんなことが起きました。

親会社・子会社のような階層構造を持つ企業の「利用ログ」テーブルに、どんなカラムを追加すべきか ― これを AI に相談していたときのことです。

私は「売上ログ側に場所 ID を直接持たせるべき」と主張しました。対して AI は「親テーブル経由で JOIN すれば解決できるので不要」と答えてきました。

ここで私が強めに言語化したのは、データ設計の教科書によく載っている一般論です。

  • マスタ系テーブル（企業・商品・契約など）は正規化する。JOIN で整合性を保つ
  • ログ系テーブル（売上・操作ログ・監査ログなど）はイベント発生時点のスナップショットで保持する。マスタが後から変わっても「その時どうだったか」を不変で残す

AI はこの原則に即座に同意しました。そして非常に示唆的な一言を残しました。

ご指摘の通り、データ設計の一般論として正しいです。私の認識不足。

……つまり、AI はこの原則を知識としては完全に持っていたのです。初見で教わったわけではない。それなのに、目の前の「新規カラム追加の是非」という具体のタスクに自発的に結びつけなかった。

今回はたまたま私がデータウェアハウス設計に経験を持っていたので指摘できました。しかし、私が詳しくない領域 ―― フロントエンドのパフォーマンス、ネイティブアプリのプラットフォーム準拠、LINE ミニアプリの WebView 制約 ―― で同じ議論が起きたら？

AI が「知っているのに使わない」瞬間を、私は検出できないまま設計が進んでしまう可能性があります。

この構造的な課題にチームで取り組むために運用を始めた、"task-kickoff" プロトコルの話をします。AIの弱点を塞ぐというよりも、AIの潜在能力を意図的に引き出す仕掛けです。

AI の「知識の保有」と「適用判断」は分離している

冒頭の出来事が示しているのは、LLM が持っている根源的な性質です。

LLM は膨大な知識を抱えています。設計パターン、業界ベストプラクティス、過去の失敗事例、OWASP Top 10、インデックス戦略、キャッシュ戦略、アクセシビリティガイドライン ―― 聞けば大抵のことは答えられます。

しかし、目の前のタスク（仕様書の一行、スキーマ変更の是非、PR のレビュー）において、その知識を能動的に引き出して適用するかどうかは、知識の保有とは別の関門なのです。

整理すると、AI の出力品質は2つの関門を通ります。

関門 内容 律速条件
関門1: 知識の保有 必要な知識がモデルに書き込まれているか 学習データ次第、個別タスクではほぼ固定
関門2: 適用判断 持っている知識から、今このタスクに関係するものを能動的に引き出せるか プロンプトの構造とタスクの粒度に強く依存

「AI はまだ知識が足りない」というよく聞く論点は、関門1の話です。そしてここはモデルの世代交代で指数的に改善してきました。

一方、関門2 ―― 適用判断 ―― は、あまり議論されてきませんでした。しかし日常業務で AI を本格的に使うと、ここが律速になる場面が頻繁に発生します。「聞けば答えるが、聞かれなかったから言わなかった」という挙動です。

これは LLM アーキテクチャの自然な帰結です。LLM はプロンプトに出現した概念と重み上近い知識を優先的に活性化するので、プロンプトに「マスタ vs ログの設計原則」という語彙が登場しない限り、その知識は関門1 にあっても関門2 を通りません。

なぜ「適用漏れ」は検出しにくいのか

問題をさらにややこしくしているのは、適用漏れが人間側の専門性に依存して検出されているという非対称な構造です。

現在、多くのチームで AI ワークフローは以下の流れで組まれています。

1. 人間が要件を定義する
2. AI に設計ドラフトを出させる
3. 人間がレビューして、気になる点を AI に質問する
4. AI が答えて、設計が洗練される
5. 実装フェーズに進む

この流れは、Step 3 で人間が「気になる点」を捕まえられることを暗黙の前提にしています。

前提が崩れるケースを考えてみましょう。

  • 人間がジュニアエンジニアで、その領域の経験が浅い
  • 人間が非エンジニア PdM で、技術的な勘が効かない
  • 人間がシニアエンジニアだが、今回のタスクが自分の専門外の領域（DB 畑のベテランがフロントエンド設計を触る等）

こうなると、AI が関門2 を通過せずに出した設計案は、誰にも問題点を指摘されないまま実装フェーズへ流れ込みます。数ヶ月後の障害や、半年後のデータ移行フェーズで初めて発覚する ―― というのが典型的な顛末です。

つまり「AI の設計力は専門家のレビューがあって初めて機能する」という隠れた前提の上に、現在の AI 駆動開発は成立していると言えます。

この前提を放置したまま AI の活用範囲を広げると、専門家不在の領域で AI の挙動が「実行力はあるが問題を見つけない作業員」のほうに寄ってしまいます。組織のスケールにとって、これは無視しづらい制約です。

解決アプローチ：タスク着手前の「強制メタ作業」

対策としてチームで始めたのは、設計系タスクの着手前に、AI 自身にメタ作業（棚卸し・想定・セルフレビュー）を強制するプロトコルでした。

狙いはシンプルです。

人間が適用漏れを検出するのではなく、AI が適用漏れを先回りで自己申告する仕組みに変える。

関門2（適用判断）を、プロンプトの構造によって半強制的に通過させる、と言い換えてもいいです。

具体的には、設計・要件定義・アーキテクチャ判断に着手する前に、以下の 6 フェーズを AI に実行させます。これを "task-kickoff" プロトコル（Phase 0-1 〜 0-6）と呼んでいます。

Phase 0-1: 業界ベストプラクティス棚卸し

タスクに関係する領域を特定し、各領域のベストプラクティスを 最低 5 件列挙させる。

  • データ設計: 正規化 / スナップショット / 整合性モデル / インデックス戦略 / トランザクション境界
  • API 設計: 冪等性 / Rate Limit / エラー伝播 / バージョニング / ページング
  • 認証・認可: OWASP Top 10 / トークン管理 / セッション / CSRF / CORS
  • フロントエンド: アクセシビリティ / パフォーマンス（LCP/CLS/INP） / SEO / i18n / 状態管理
  • ベンダー固有: Stripe Webhook の再送挙動 / LINE LIFF の Cookie 制約 / Akerun の API 権限モデル

各項目について [適用 / 適用外 / Tradeoff あり] を判定させ、適用外なら理由を、Tradeoff なら本プロジェクトでのスタンスと根拠を言語化させます。

狙いは、関門1で持っている知識の可視化。ここで明示的に棚卸ししておけば、後続のレビュー時に「これは適用した / しなかった」の判断が透明になります。

Phase 0-2: 暗黙前提の言語化

設計で無意識に置いている仮定を洗い出させます。

  • 「ユーザーは常に同時 1 セッションで操作する」
  • 「ネットワークは常に正常」
  • 「外部 API は常に応答する」
  • 「データ移行が必要になるのは ○○ のタイミングだけ」

各仮定について 「崩れたときのシナリオ」「影響範囲」「確実度（High/Medium/Low）」 を出力させます。

暗黙の前提は「言語化されない」がゆえに、後で炎上します。言語化自体を AI にやらせることで、人間の専門性への依存を減らせます。

Phase 0-3: Pre-mortem

「6 ヶ月後、本機能を起因とした障害が発生した。」

このシナリオで考えうる原因 トップ 5 を列挙させ、発生確率と影響度で整理させます。

Pre-mortem は組織論では古典的な技法ですが、LLM にやらせると特に相性が良いです。理由は単純で、LLM は「過去のあらゆる障害事例」を学習データに抱えているからです。Phase 0-3 はその知識を強制的に引き出すトリガーになります。

Phase 0-4: Multi-Persona セルフレビュー

以下から関連する 3 〜 7 ペルソナを選定させ、それぞれの視点で赤旗を挙げさせます。

  • Senior DB Architect: 整合性・スケーラビリティ・クエリコスト
  • Security Engineer: OWASP 観点・脅威モデル・データ保護
  • Frontend Engineer: UX・アクセシビリティ・パフォーマンス・ブラウザ互換
  • SRE: 障害時動作・運用負荷・可観測性・デプロイリスク
  • Junior Engineer: 「これ何のため？」「このコード読める？」
  • PdM: ビジネス価値・スケジュール・顧客影響・競合比較
  • Data Engineer: 分析への影響・データウェアハウス整合性

実運用では、ペルソナを 1 つずつ独立した LLM 呼び出しに分けると、視点混ざりが減って精度が上がります。

Phase 0-5: 自信度マトリクス

設計の各部分について自信度を開示させます。

  • High: 業界で確立されたパターン、過去類似実装の経験豊富
  • Medium: 一般論は知っているが、本プロジェクト固有条件で揺れる
  • Low: 知識不足、外部レビュー推奨

Low と判定された領域は、「どの専門家・一次情報源に当たるべきか」を名指しさせます。可能なら公式ドキュメント・RFC・書籍まで。

これが効く理由は、人間側が "自分の専門外"を事前に認識できるからです。関門2 の検出責任を、人間の勘から AI の自己申告へと移譲する仕掛けです。

Phase 0-6: Alternative Design

最低 3 つの設計アプローチを提示させ、それぞれの：

  • 長所・短所
  • 採用基準（どういう条件ならこの案が最適か）
  • 本プロジェクトでの推奨度

を言語化させます。単一案のみの提案は禁止というのがポイントです。

これは思考停止の防止装置です。LLM は「それっぽく見える一案」を出す能力が高いので、意識的に複数案を要求しないと、人間側がそれを「唯一の選択肢」と誤認してしまうリスクがあります。

サンプルプロンプト（そのままコピペで使える）

実際に使っているプロンプトテンプレートを貼っておきます。設計系タスクに入る前に、これをまるごと AI に投げます。

このタスクの設計に着手する前に、以下の Phase 0-1 〜 0-6 を順番に実行してください。
各 Phase の結果を構造化して出力してから、詳細設計に進んでください。

## Phase 0-1: 業界ベストプラクティス棚卸し
このタスクに関係する領域（データ設計・API設計・認証・外部連携・
フロントエンド等）を特定し、各領域のベストプラクティスを最低 5 件
列挙してください。各項目に [適用 / 適用外 / Tradeoff あり] を判定し、
判定理由を添えてください。

## Phase 0-2: 暗黙前提の言語化
この設計で無意識に置いている仮定を 5 件以上列挙し、それぞれ
「崩れるシナリオ」「影響範囲」「確実度(High/Medium/Low)」を
明示してください。

## Phase 0-3: Pre-mortem
「6 ヶ月後、この機能を起因とした障害が発生した」というシナリオで、
考えうる原因トップ 5 を発生確率・影響度で整理してください。

## Phase 0-4: Multi-Persona セルフレビュー
タスクに関連する 3 〜 7 のペルソナを選定し、それぞれの視点で
赤旗を指摘してください。ペルソナごとに独立にレビューしてください。

## Phase 0-5: 自信度マトリクス
設計の各部分について High / Medium / Low で自信度を開示し、
Low の領域は「どの専門家・一次情報源に当たるべきか」を名指ししてください。

## Phase 0-6: Alternative Design
最低 3 つの設計アプローチを提示し、各案の長所・短所・採用基準・
本プロジェクトでの推奨度を言語化してください。

出力は長くなります。Phase 全部で 3,000 〜 5,000 トークンくらい使うのが普通です。ただ、この 30 秒の投資で、後工程の数時間〜数日分の手戻りが予防されると考えると、非常にペイのよい投資です。

実装：3つの組み込み方

プロンプトを都度投げるだけでは運用が続きません。以下の3つのどれか（または組み合わせ）に埋め込むのが現実的です。

1. スキル化 / サブコマンド化

Claude Code なら Skill として定義し、/task-kickoff で呼び出せるようにします。Cursor なら Custom Mode、ChatGPT なら GPTs として登録できます。

ポイントは人間が発動を意識しなくていい状態を作ることです。親エージェントのシステムプロンプトに「設計系タスク着手時は task-kickoff を必ず発動する」と明記しておけば、人間は /task-kickoff すら打たなくて済みます。

2. CLAUDE.md / プロジェクトルールへの組み込み

リポジトリ直下の CLAUDE.md（あるいは相当するルールファイル）に以下を追加します。

## 設計系タスクの着手ルール

以下に該当するタスクに着手する前には、必ず task-kickoff プロトコル
（Phase 0-1 〜 0-6）を実行すること。

- 新機能の要件定義
- DB スキーマ設計
- API 設計
- アーキテクチャ判断（マイクロサービス分割、キャッシュ戦略など）
- セキュリティ設計
- 外部システム連携設計
- フロントエンドの新規画面・新規状態管理

こうしておくと、CLAUDE.md を読み込むコンテキストでは自動適用されます。

3. PR テンプレート統合

PR を出す段階で Phase 0-1 〜 0-6 の結果を description に貼ることを義務化します。

## Pre-Design Meta
<!-- Phase 0-1 〜 0-6 の結果を貼ってください -->

## 変更概要

## 実装詳細

## 動作確認

これは組織の監査トレイルとしても機能します。後から「なぜこの設計になったのか」を追いかけるとき、当時どの知識を適用し、何を棄却し、どこに自信がなかったかが永続化されます。設計意図を引き継ぐドキュメントとしても再利用できます。

「AIがレビュー項目を列挙する」という新しいリーダーシップ

もう一段メタな話をします。

AI の活用が組織全体に広がると、エンジニアリングリーダーの仕事も変わります。従来のリーダーシップは、ざっくり以下のような構造でした。

  • 設計レビューを主催する
  • 自分の知識・経験から赤旗を指摘する
  • ジュニアに「これはこう考えるんだよ」と教える

AI ネイティブな組織では、この「赤旗を指摘する役」を人間 1 人に依存するのは構造的に厳しくなります。組織が扱う領域は増え続け、全領域に精通したレビュアーは現実的には存在しません。

代わりにリーダーに求められるスキルは、次の一行に凝縮されると考えています。

「何をレビューするか」を AI に列挙させる能力。

task-kickoff プロトコルは、この能力の小さな実装です。Phase 0-1 で AI に業界ベストプラクティスを列挙させるのは、「今回のレビューで見るべき項目は何か」を AI に先に言わせる行為にほかなりません。人間は、AI が挙げてきた項目群をメタに眺めて、抜け漏れや強弱を判断することになります。

レビューの一次筆記を AI に任せ、人間は二次編集・採否判断・戦略的方針づけに専念する ―― という形にシフトしていきます。冒頭の DB 設計の例に戻るなら、私が指摘するまで AI が「マスタ vs ログ」の話を出さなかったのは課題でしたが、Phase 0-1 で事前にデータ設計のベストプラクティスを列挙させていれば、そのリストには確実に「マスタ vs ログ」が入っていたはずです。人間側の知識に頼らずに同じ水準のレビューを成立させられる、というのがプロトコルの価値です。

つまり、task-kickoff プロトコルは AI の扱い方の工夫であると同時に、人間の専門性への依存度を下げる組織設計ツールでもあります。ジュニアエンジニアが 1 人で AI と向き合っても、シニアが不在の領域に踏み込んでも、最低限のレビュー観点が抜け落ちない ―― そういう状態を作れる点が、個人向けの生産性 Tips と一線を画すところです。

まとめ

項目 従来 task-kickoff 運用後
関門2（適用判断）の担い手 人間のレビュー AI の自己申告 + 人間の採否
レビュー品質の律速 人間の専門知識 プロトコルの網羅度
専門家不在領域の設計品質 検出漏れが通過しやすい ベースラインを担保できる
リーダーの時間配分 赤旗指摘中心 AI が挙げた項目の採否・戦略判断

AI は「知識の保有」と「適用判断」が分離している ―― この性質は、モデルの世代交代を待たなくても、プロンプトの構造で扱えます。人間側の専門知識に寄りかかる代わりに、AI 自身に棚卸し・Pre-mortem・複数ペルソナレビュー・自信度開示・Alternative Design を先にやらせる。これが task-kickoff プロトコルの骨子です。

次に AI に「この機能の DB 設計お願い」と投げる前に、一度だけ試してみてください。

「このタスクに関係するベストプラクティスを、まず 5 件棚卸してみて」

30 秒のうちに、AI が持っていたはずの知識が一気に可視化されます。その後の設計品質は、多くのケースで一段変わります。

AI 時代の設計レビューは、「人間がレビューする」から「AI がレビュー項目を列挙し、人間が判断する」へゆっくり移っていきます。task-kickoff プロトコルは、その移行を個人・チーム単位で始めるための、最小限の足がかりです。

GitHubで編集を提案

Discussion