見出し画像

Claude Fable5のUnknowns手法から考える、Codex開発でまだ知らない問題を先に見つける方法

南翔伍 / AIコンパニオンとSNSの間くらいの「Jams」開発中

要件を細かく書いた。実装計画も作った。テストも通った。それでも、完成したものを見ると「違う」と感じる。

AIコーディングでは、この失敗が珍しくありません。原因をモデル性能やプロンプト不足だけに求めると、指示はさらに長くなります。しかし、長い指示が正解とは限りません。間違った前提を詳しく固定すれば、AIはより正確に間違った方向へ進むからです。

Claude Fable 5との開発についてThariq氏が示したのは、この失敗を「Unknowns、つまり現時点では把握できていない未知」の問題として捉える考え方でした。重要なのは、未知を完全になくすことではありません。実装前、実装中、実装後に未知を発見し、判断が変わる場所で止まり、必要な工程へ戻れるようにすることです。

ただし、この考え方をCodexのすべてのskillへ追加すればよいわけでもありません。ここでいうskillとは、Codexへ繰り返し使う手順、判断基準、参考資料、必要なスクリプトをまとめた再利用可能な仕事の型です。要件定義、局所的な実装計画、差分レビュー、目的達成の監査、セッション記録には、すでに不確実性やリスクを扱う仕組みが含まれている場合があります。

全skillへ同じ知識を重ねると、質問、文書、トークン、責務の重複が増えます。

私の結論は、まず短い追加プロンプトで差分価値を検証し、既存skillでは拾えなかった重要な未知だけを最小限組み込むべき、というものです。

※この記事は、提供資料に収録されたThariq氏の投稿内容と、実際のCodex skill群を照合した検討記録を基礎にしています。Thariq氏の投稿は公開URLを確認できていないため、投稿内容は提供資料に基づいて紹介します。Claude Fable 5とCodex Skillsの現行仕様は、AnthropicとOpenAIの公式情報で再確認しています。


指示という地図を詳しくしても現実の領土とは一致しない

Thariq氏は「地図は領土ではない」という比喩を使っています。

ここでいう地図は、プロンプト、skill、文脈情報、仕様書、実装計画など、AIへ渡す仕事の表現です。領土は、実際のコードベース、ユーザーの行動、運用、権限、例外、過去の設計判断です。その差に未知があります。

人間が「十分に説明した」と思っていても、AIは実装の深部で新しい制約に遭遇します。既存コードの設計が想定と違うかもしれません。エッジケースによってデータモデルを変える必要が出るかもしれません。プロトタイプを見た瞬間に、依頼者自身が「欲しかったのはこれではない」と気づくこともあります。

Claude Fable 5は、Anthropicが長時間かつ複数段階の知識労働やコーディング向けに提供するモデルです。長い仕事を継続できる能力が高まるほど、最初の問題設定や評価基準がずれたまま大量の作業を進めるリスクも大きくなります。

モデルが弱いときは、AIの生成能力がボトルネックでした。モデルが強くなるほど、人間側の目的設定、暗黙知の言語化、評価基準、未知の発見能力が制約になります。これは「プロンプトが不要になる」という話ではありません。プロンプトだけでは扱えない領域が、相対的に大きくなるということです。

優れたエージェント開発者は、望むものを詳細に理解し、コードベースとモデルの挙動へ深く同期しています。そのため未知が少ない。ただし、未知がゼロだとは考えていません。未知が残る前提で、探索、試作、質問、レビュー、停止条件を設計します。

四つの未知は同じ方法では扱えない

Unknownsは四つに分けられます。この分類の価値は名前を覚えることではなく、未知の種類によって対処を変えられる点にあります。

すでに分かりAIへ伝えていること

Known Knownsは、自分が知っており、AIへ伝えていることです。

実務では、目的、期待する出力、使用技術、制約、完了条件などが該当します。通常の要件定義や実装計画で扱えます。

分からないことを自覚していること

Known Unknownsは、答えは分からないものの、未決定であることは認識している領域です。

認証方式、データモデル、既存APIの適合性、性能要件、運用方法などが該当します。調査、比較、質問、意思決定によって埋められます。

見れば判断できるのに言葉へできていないこと

Unknown Knownsは、自分の中に基準があるのに、明示できていない領域です。

画面を見れば「違う」と分かる。既存実装を見れば「この書き方は自社らしくない」と分かる。業務担当者は例外を経験的に避けているが、ルールとして説明していない。こうした暗黙要件は、質問だけでは出てこないことがあります。

この未知には、複数案、参考実装、モック、プロトタイプが有効です。見て反応することで、初めて判断基準を言葉へ変えられます。

問うべきことの存在さえ知らないこと

Unknown Unknownsは、検討すべき問いがあること自体を認識していない領域です。

知らないセキュリティリスク、過去障害、業界固有の慣行、コードベース固有の制約、より良い別解、そもそも別の問題を解くべき可能性などが該当します。

この未知は、通常の要件確認だけでは拾いにくい。Blind Spot Pass、コード探索、参考実装、代替となる問題設定、専門知識の学習が必要です。

指示は細かすぎても曖昧すぎても失敗する

AIへの指示には、微妙なバランスがあります。

細かすぎる指示は、方向転換すべき場面でもAIを拘束します。曖昧すぎる指示は、AIが一般的なベストプラクティスで穴を埋めます。しかし、その一般解が対象コードや業務に合うとは限りません。

ここで有効なのが、要求を三つへ分ける考え方です。

  • 変更してはいけない固定事項

  • 目的を守る範囲でAIが調整してよい裁量事項

  • 人間の確認が必要な要確認事項

これはThariq氏の投稿にある正式な分類ではなく、Unknowns手法を開発運用へ応用した整理です。

実装計画を「すべて守る契約」にするのではなく、「何を守り、どこで調整し、どこで止まるかを定める契約」に変える。これにより、計画へ忠実であることと、目的へ忠実であることを分けられます。

AIを完成品の生成器としてだけ使うと、未知は実装後に露出します。AIを未知発見の共同思考者として使えば、コードベース検索、外部調査、比較、説明、試作を通じて、早い段階で未知を見つけられます。

そのためには、AIへ現在地を伝える必要があります。

何を知っているのか。何を知らないと認識しているのか。どの領域の経験がないのか。何を決めたいのか。まだ実装を始めるべきでないのか。

これがBlind Spot Passの前提になります。

問題設定や問いの作り方を、プロンプトより前の工程として考えたい場合は、別の記事で「問いの編集力」として詳しく整理しています。

実装前は作るより先に未知を見つける

Thariq氏の投稿では、実装前に複数の技法が示されています。毎回すべてを使うのではなく、未知の種類に応じて選びます。

Blind Spot Passは問いの存在を探す

新しいコード領域、未経験の作業、デザインなど、Unknown Unknownsが多いときに使います。

提供資料に収録された投稿には、認証モジュールを何も知らない状態で、新しい認証プロバイダーを追加する前にBlind Spot Passを依頼する例があります。色調補正を知らない状態で、より良い依頼を作るために未知を教えてもらう例もあります。

重要なのは「一般的な注意点を列挙して」と頼むことではありません。対象コード、既存仕様、設定、テスト、運用を調べ、この案件固有の判断変更要因を探させることです。

実務では、次のように依頼できます。

まだ実装せず、このタスクについてBlind Spot Passを行ってください。

私が認識している要件だけでなく、コードベース、既存仕様、運用、セキュリティ、例外処理を調べ、まだ認識できていない重要な未知を特定してください。

一般的な注意事項の羅列ではなく、この案件固有の根拠を示してください。

各論点について、重要性、見落とした場合の影響、確認方法、方針を変えうる質問を整理してください。

最後に、発見した未知を反映した改善版の実装指示を提示してください。実装はまだ開始しないでください。

認証のような高リスク領域では、認証フロー、セッション、トークン、Cookie、アカウント統合、リダイレクト、権限、CSRF、state、nonce、PKCE、シークレット、環境差、テスト、移行、ロールバックまで探索対象へ含められます。

ただし、これらの詳細項目はThariq氏の投稿に並んでいたものではありません。認証実務へ応用した確認項目です。

複数案と試作品は暗黙要件を表へ出す

「ダッシュボードが欲しいが、良い見た目が分からない」という状態で、いきなり本番実装へ進む必要はありません。大きく異なる四つのHTML案を作り、反応すればよい。

新しいエディターツールバーの配置を確認したいだけなら、バックエンドや状態管理をつながず、偽データの単一HTMLで確認できます。

オンボーディング後の離脱を減らしたいなら、最初から一つの施策へ決めず、コードベースを調べ、安価な案から大規模な案まで複数出させられます。

この工程は、AIの実装能力を試すためではありません。人間のUnknown Knownsを発見し、仕様へ変換するためです。

インタビューは判断を変える質問から始める

ブレインストーミング後も曖昧さは残ります。そのとき、AIへ一問ずつ質問させます。

優先するのは、答えによってアーキテクチャ、データモデル、権限、利用者の体験、スコープが変わる質問です。好みの細部から聞くのではなく、後戻りコストが大きい論点から確認します。

参考実装は説明できない要望を伝える

言葉で説明できないなら、参考資料を渡します。図、文書、画像も使えますが、実装の意味まで伝えたいならソースコードが強い。

別言語のライブラリでも構いません。「このRust実装の再試行間隔の考え方を読み、TypeScriptのAPIクライアントへ同じ挙動を再実装して」と指定できます。

参考画面だけでなく、対応するマークアップ、構造、実装詳細を読ませることで、表面の見た目を超えた要件を共有できます。

実装計画は判断が変わる部分を先に置く

実装計画を作るとき、機械的なリファクタリングを先頭へ並べても、人間の判断には役立ちません。

先に確認すべきなのは、データモデル、型の取り決め、利用者の流れ、外部から見える変更など、後から変えると高くつく部分です。信頼できる機械的作業は後段へ置きます。

実装中に重要なのは計画へ従うことより逸脱を扱うこと

どれだけ計画しても、実装中に新しい未知は出ます。

既存コードの制約により、計画どおりの方法が危険になる。エッジケースで追加状態が必要になる。予想外の呼び出し元が見つかる。より安全な既存パターンが見つかる。

Thariq氏の投稿では、一時的な実装ノートを維持し、計画から逸脱した判断を記録する方法が提案されています。保守的な選択をして継続し、その理由を逸脱記録へ残す考え方です。

ただし、既存のCodex運用へ新しい`implementation-notes.md`を必ず増やすべきとは限りません。確認したセッション終了用skillは、汎用的な実装ノートを作らず、そのリポジトリで既に使っている記録へ集約する方針を持っていました。

必要なのは新しいファイルではなく、少なくとも次を既存記録へ残すことです。

  • 未解決事項

  • 守るべき不変条件

  • 次の一手

  • 今回得た学び

  • 計画からの逸脱

  • AIが独自に確定した判断と理由

安全かつ可逆で、既存パターンに沿う変更は保守的に進めてもよい。一方で、仕様、アーキテクチャ、データ、権限、セキュリティ、外部副作用を変える事項は、AIが勝手に確定すべきではありません。

実装後は差分だけでなく判断過程も監査する

実装後には二つの課題があります。

一つは、関係者の理解と承認を得ることです。プロトタイプ、仕様、実装中の判断を、レビュー可能な一つの説明へまとめます。

もう一つは、所有者が変更を理解しているか確認することです。長いセッションでは、AIが人間の認識以上の変更を行うことがあります。差分だけでは、既存コードの経路に依存する挙動まで理解できません。

Thariq氏の投稿では、変更内容の説明とクイズを作り、理解できるまで統合しない方法が紹介されています。

ただし、理解度クイズをすべての変更へ必須化するのは過剰です。認証、課金、データ移行、権限、外部送信など、理解不足が事故へ直結する変更に限定する方が合理的です。

通常の実装後レビューで不足しやすいのは、次の観点です。

  • 実装中に発見された未知

  • 暗黙に置かれた仮定

  • 計画からの逸脱

  • AIが独自判断した事項

  • 未解決事項

  • 既存コードの経路への影響

  • ロールバック時に失われる状態

この観点は、後で扱う既存skillの中でも、恒久追加の価値が最も高い候補です。

CodexとClaude Codeを使う開発工程全体を、要件、計画、実装、検証、レビューへ分ける方法は、こちらの記事で詳しく整理しています。

動画制作の事例は作る前に評価できる状態を作る重要性を示す

Fableのローンチ動画では、Claude Codeが映像編集に使われました。作り手は、コードで動画編集できることと文字起こしできることは知っていました。しかし、文字起こしの精度、フィラー削除、長い間のカット、発話同期UI、色調補正については分かっていませんでした。

最初は、Whisperとffmpegで何ができるかを説明させました。次に、Remotionと文字起こしを使った小さな動画で、発話とUIの同期が成立するか試しました。

色調補正では、当初は複数案を作らせようとしました。しかし、そもそも何が良い色調補正なのか分からない状態では、案を増やしても判断できません。

そこで依頼を「複数案を作る」から「色調補正を教え、まだ知らない論点を発見する」へ変えました。

ここにUnknowns手法の本質があります。

AIへ何かを作らせる前に、人間が評価できる状態を作る。未知が大きいときは、生成量を増やすより学習と試作へ戻る。これはコード、デザイン、動画、業務設計に共通します。

全skillへ追加する案は一見合理的でも重複を増やす

Unknowns手法を日々のCodex開発へ使うため、当初は`unknowns-management`という共通skillを作る案が考えられました。

構想は三層です。

  • 共通のUnknowns skill

  • 要件定義、実装計画、実装、レビューへの軽量な組み込み

  • 未知の一覧、実装ノート、レビュー報告などの工程間成果物

四つの未知を分類し、アーキテクチャ、セキュリティ、データ、利用者の体験、後から直せる事項へ分け、固定事項、裁量事項、要確認事項、保留事項を管理する案でした。

一見すると整っています。しかし、実際の既存skillと照合すると問題が見えます。

  • Thariq氏の投稿は方法論であり、完成した運用仕様ではない

  • 既存skillと重複する可能性が高い

  • 全工程で同じ分類を出すと文書とトークンが増える

  • 小さな変更へ過剰適用される

  • skill間でルールがずれる

  • どの要素が効いたか検証できない

  • 未知の一覧や実装ノートが既存記録と重複する

そのため、全skillへの即時追加ではなく、先に短い追加プロンプトで差分効果を試す方針が妥当です。

AI開発の仕組み化では、未検証の方法をルールへ固定すること自体が新しいリスクになります。

短い追加プロンプトは恒久解ではなく実験装置になる

即時skill化には、自動適用、再現性、複数エージェントの一貫性、長期的な入力負荷削減という利点があります。

一方、短い追加プロンプトには、既存skillを壊さず、必要な仕事だけで試し、単独効果を比較できる利点があります。失敗しても戻しやすく、質問や出力が過剰かどうかも確認できます。

弱点もあります。毎回入力が必要で、表現が揺れ、忘れる可能性があり、複数エージェントへ一貫して適用しにくい。

したがって、短いプロンプトは最終形ではありません。skill化前の検証器です。

検証では次を見ます。

  • 既存skillでは出なかった重要論点が増えたか

  • 出た論点のうち実際に有効だった割合

  • 一般論や誤検知が増えなかったか

  • 実装方針やスコープが変わったか

  • 手戻りとレビュー指摘が減ったか

  • 質問負荷とトークン増加に見合うか

  • 所有者の理解が深まったか

検討過程では、五件から十件、別案では五件から八件程度の実案件が候補になりました。これは確定基準ではありません。異なる種類の仕事で再現性を見るための暫定的な目安です。

既存七つのskillにはすでに多くの未知対策がある

実際のCodex skill群を確認すると、Unknowns手法と重複する機能が多くありました。

文書化前の問題設定には追加の余地がある

`document-first-implementation-planner`は、必要文書、正式な情報源、完了条件、未確認事項、リスク、文書競合、人間の判断を扱います。実装準備の判定は強い。

不足候補は、そのさらに前です。

  • そもそも別の問題を解くべきではないか

  • 既存機能で代替できないか

  • 依頼者がまだ言葉にできていない暗黙要件はないか

  • 参考実装や試作を見なければ決められないのではないか

このskillへ即時追加するのではなく、まず短いプロンプトで、要件やアーキテクチャを実際に変える論点が増えるか試すべきです。

実装計画の品質ゲートはすでに探索力が強い

`implementation-planning-quality-gate`は、検索語、候補ファイル、実際に読んだファイル、現行構造、正式な情報源、影響範囲、未読の重要箇所、リスク、完了条件、ロールバックを扱います。

証拠を先に確認する設計であり、計画前の停止条件もあります。そのため、Blind Spot Passの大部分は重複します。

追加価値があるとすれば、既知の未決定事項の確認ではなく、見なければ判断できない暗黙要件を、試作や比較案によって発見する部分です。画面、成果物の見た目、曖昧な作業方式などに限って検証する方がよいでしょう。

局所計画を作るskillは薄い変換器のまま保つ

`create-plan`は、承認済みの上流設計を局所的な実装計画へ変換する役割です。

ここへ探索やBlind Spot Passを追加すると、上流設計と局所計画の責務が混ざります。原則として変更しない方がよい。

例外は、局所範囲を超える証拠が出たときに、計画を勝手に拡大せず、上流工程へ戻す短い停止規則です。

実装後レビューが最も有力な追加先になる

`implementation-diff-repair-review`は、差分、回帰、セキュリティ、データ、権限、例外、テスト、ロールバックを確認します。

不足候補は、実装中の判断過程です。

  • どの未知が発見されたか

  • どの仮定を置いたか

  • どこで計画から逸脱したか

  • 何をAIが独自に決めたか

  • 何が未解決か

この観点は既存の差分レビューへ自然に追加でき、独立価値も高い。七つのskillの中では、恒久変更の最有力候補です。

目的達成の監査へクイズを常設する必要はない

`goal-audit`は、目的達成、証拠、検証、残存リスク、最終判定を扱います。

所有者の理解確認は有効ですが、すべての仕事へクイズを付ける必要はありません。認証、課金、移行、権限、外部送信など、理解不足が事故へ直結する変更でのみ追加する方がよい。

セッション記録へ新しい汎用ファイルを増やさない

`close-session-work`は、既存のリポジトリ固有の記録へ状態を残し、汎用的な実装ノートを作らない設計です。

そのため、Unknowns専用記録を新設するより、未解決、不変条件、次の一手、学び、逸脱を既存記録へ圧縮します。

自動レビューへ常時追加しない

`autoreview`は、使用条件、コスト制御、レビュー契約を持っています。

Unknowns探索を常時追加すると、レビューコストが増え、責務が曖昧になります。必要な場合に上位skillから呼ぶ方がよい。

Codexのskillは、手順や参考資料を再利用可能な形へまとめ、必要なときだけ詳しい内容を読み込む仕組みです。だからこそ、何でも一つのskillへ詰め込むより、責務を狭く保つ方が運用しやすい。

Codexのレビュー規則、AGENTS.md、テスト、CIをどう分けるかは、こちらの記事で詳しく整理しています。

検証するなら三つの工程に絞る

全skillを同時に変えると、どの変更が効いたか分かりません。最初は三つに絞るべきです。

要件定義前に問題設定と代替を疑う

まだ実装せず、このタスクについて対象コードと既存仕様を調査したうえでBlind Spot Passを行ってください。

明示した要件だけでなく、まだ認識していない可能性がある重要な制約、暗黙の前提、既存実装との衝突、別解、セキュリティ、運用、互換性上の論点を抽出してください。

特に、回答によってアーキテクチャ、データモデル、権限、実装範囲が変わる事項を優先してください。

一般論とコードベース固有の事実を分け、確定事項、推測、未確認事項を区別し、最後に実装前に決めるべき事項だけを提示してください。

ここでは、要件不足の確認だけでなく、別の問題設定、既存機能による代替、小さな試作が必要な暗黙要件を探します。

局所的な実装計画の前に範囲拡大条件を探す

この変更範囲に限定してBlind Spot Passを行ってから、局所的な実装計画を作成してください。

関連する呼び出し元と呼び出し先、既存パターン、型、状態、データ、権限、テスト、例外、互換性を確認し、想定より変更範囲が広がる条件や、計画を変えうる未知を先に示してください。

計画は、人間が判断すべき事項、外部挙動、データモデルや型、リスクと検証方法を先頭にし、機械的な編集手順は後段に置いてください。

ただし、既存の計画品質ゲートと出力がほぼ同じなら、恒久追加は不要です。

実装後レビューで判断と逸脱を監査する

実装結果を、要件適合、回帰、セキュリティ、データ整合性、権限、例外処理、テスト、ロールバックの観点に加えて、実装中に発見された未知、暗黙に置かれた仮定、計画からの逸脱、Codexが独自判断した事項、未解決事項の観点からレビューしてください。

コード差分だけでなく、関連する既存コードの経路も確認してください。

確認済み事実と推測を区別し、重大度順に問題、根拠、影響、修正案、追加検証を示してください。

この差分が複数の仕事で有効なら、`implementation-diff-repair-review`へ短い確認観点として組み込む価値があります。

新しいskillを作るなら問題設定前の探索だけが候補になる

新規skillを無理に作る必要はありません。

独立した価値があり得る候補は`unknowns-discovery`です。役割は、要件化や実装計画より前に、問題設定と解法の未知を発見することです。

既存skillとの違いは明確でなければなりません。

  • 文書化のskillは、何を文書化すべきか決める

  • 計画品質のskillは、実装計画を証拠に基づいて作る

  • 局所計画のskillは、承認済み設計を作業手順へ変換する

  • 差分レビューのskillは、実装済み変更を監査する

  • 目的監査のskillは、最終目的の達成を監査する

  • `unknowns-discovery`は、その前に今の問題設定や解法を固定してよいか探索する

使う場面は限定されます。

  • 新しい領域で何を質問すべきか分からない

  • 見れば分かるが言語化できない

  • 依頼が最初から特定の解決策へ固定されている

  • 同種の手戻りが繰り返されている

  • 大量展開前に小さく方向を確認したい

使わない場面も明確です。

  • 範囲と完了条件が明確な小さな修正

  • 承認済み設計から局所計画を作るだけの仕事

  • 実装済み差分のレビュー

  • 単純な説明や調査

  • 既存skillで十分に未知を処理できる仕事

内部の動きは五つに整理できます。

  • Blind Spot Pass

  • 別の問題設定の探索

  • 試作品による暗黙要件の発見

  • 判断を変える質問

  • 参考実装の探索

成果物は大きな台帳ではなく、短い探索メモで十分です。

  • 現在の問題設定

  • 確認した証拠

  • 判断を変える未知

  • 見落とし候補

  • 別の問題設定

  • 次に行う最小探索

  • 推奨する後続工程

停止条件も必要です。

  • 判断変更要因がなくなった

  • 次の最小探索が一つに絞れた

  • 人間の判断が必要になった

  • 既存skillへ引き渡せる状態になった

  • 一般論しか出なくなった

禁止事項は、未知を無限に列挙すること、実装を始めること、既存skillの成果物を重複して作ること、未知の一覧作成自体を目的化することです。

作らないskillを決めることも設計である

新しい考え方を得ると、それぞれをskillへ分けたくなります。しかし、次は現時点で新設しない方がよいと判断できます。

実装ノート専用skillは既存記録と重複する

セッション記録や案件記録と重複し、記録ファイルを増やします。必要な情報は、そのリポジトリで既に使っている記録へ統合できます。

逸脱管理専用skillは工程境界を増やす

実装中の逸脱だけを独立skillにすると、実装skillとレビューskillの境界が増えます。まず実装後レビューの確認観点として扱う方が軽い。

所有者理解クイズ専用skillは日常変更には重い

すべての変更には過剰です。高リスクな仕事に限り、目的達成の監査へ追加する方がよい。

プロトタイプ専用skillは目的が広すぎる

プロトタイプはUnknowns発見以外にも使われます。専用skillを作る前に、既存のデザインや実装skillとの責務整理が必要です。

Blind Spot Pass専用skillは範囲が狭すぎる

名前が一つの技法に寄りすぎ、別の問題設定、参考実装、判断質問、試作を包含しにくい。新設するなら、より広い`unknowns-discovery`の内部手法にする方がよい。

未知の台帳専用skillは記録を目的化しやすい

台帳作成自体が目的になりやすく、正式な情報源、未解決事項、決定記録と重複します。

skill化は再現性と追加価値を確認した部分だけに限る

正式にskillへ組み込む条件は、次のように置けます。

  • 複数種類の仕事で再現した

  • 既存skillでは拾えない重要論点を出した

  • 実装判断、アーキテクチャ、範囲を実際に変えた

  • 手戻りやレビュー指摘を減らした

  • 質問とトークンの増加に見合った

  • 毎回の手動入力より自動適用の便益が大きい

  • 既存skillとの責務境界を明確に書ける

不採用条件も同じくらい重要です。

  • 一般論しか出ない

  • 既存skillと同じ結果になる

  • 不要な質問が増える

  • 小さな仕事が重くなる

  • 四分類や台帳が成果へ寄与しない

  • 記録が既存成果物と重複する

採用する場合も、巨大な共通skillから始めるべきではありません。

最初の恒久変更候補は、実装後レビューへの短い確認観点の追加です。次に、文書化前の問題設定探索が独立して再現した場合のみ`unknowns-discovery`を作る。この順番が妥当です。

次に行うべきことはskill作成ではなく小さな比較実験である

現時点で行われたのは、方法論の整理、既存skillの読解、重複評価、新規skillの企画までです。

まだ行われていないことがあります。

  • 既存skillの修正

  • 新規skillの作成

  • 実案件での比較実験

  • 効果測定

  • 採用基準の確定

したがって、ここまでの提案を「検証済みのベストプラクティス」として扱うべきではありません。

次に進む実務手順は、次の順です。

まず、異なる種類の実案件を選びます。新しい認証領域、既存機能への小変更、画面の暗黙要件、データ移行、外部API統合など、未知の種類が異なる仕事が適しています。

次に、既存skillだけで実行した場合の出力を記録します。その後、要件定義前、局所計画前、実装後レビューのいずれかへ短い追加プロンプトを入れます。

比較するのは文章量ではありません。

実装判断を変えた論点、早期に止められた誤り、手戻り、レビュー指摘、質問負荷、トークン、所有者理解を比較します。

有効だった文だけを抽出し、最小の形で既存skillへ追加します。独立価値が複数の仕事で再現した場合だけ、`unknowns-discovery`を新設します。

AI開発で重要なのは未知を消すことではなく戻り道を作ること

AIコーディングが強くなるほど、詳細な指示は重要になります。しかし、詳細さだけでは足りません。

人間が知らないことを、最初からすべて書くことはできないからです。

必要なのは、実装前に問いを発見し、見なければ分からない要件を試作で表へ出し、実装中の逸脱を記録し、実装後にAIの独自判断を監査する工程です。

同時に、その工程を過剰に制度化しないことも重要です。新しい方法論を見つけるたびにskill、台帳、ファイル、必須質問を増やせば、AI開発は再び重くなります。

私が推奨する順序は三つです。

まず、短いプロンプトで未知探索の差分価値を測る。

次に、効果が最も期待できる実装後レビューの確認観点を最小追加する。

最後に、要件化前の独立した探索価値が再現した場合だけ`unknowns-discovery`を作る。

AI開発の品質を決めるのは、未知がないことではありません。未知が現れたときに、どこで止まり、誰が判断し、どの工程へ戻るかが設計されていることです。

出典・参考資料

いいなと思ったら応援しよう！

南翔伍 / AIコンパニオンとSNSの間くらいの「Jams」開発中 社会問題×マーケティングが好き / ㍿小さな一歩（前澤ファンド出資先）で養育費の未払い問題にビジネスでトライ→㍿SHIRO創業。社会問題の発見→要因分析→ビジネス考案→実行に必要な資本整備→実行・改善のサイクルが最短で回り社会問題が解決されつづけるインフラを創る。