【ITニュース解説】Compass, Steering Wheel, Destination — Framework for Working with AI on Code

AIはプログラミングの効率を飛躍的に高める可能性があるが、それと同時に、開発の方向性が意図せずずれてしまったり、AIが事実に基づかない情報（ハルシネーション）を生成したり、明確な根拠を持たない複雑な解決策を提示したりといった課題も生じることがある。これらの課題に対処し、AIを活用した開発を集中させ、意図的で、かつ適切に文書化されたものにするために、「Compass, Steering Wheel, Destination」というフレームワークが提案されている。

このフレームワークは、AIと協調してコード開発を進める際の、個人的な経験から得られた作業の流れを体系化したものである。これは公式な枠組みではなく、チーム内で共有し、共通言語として活用されることを目的としている。開発のプロセスを航海に例えると、コンパスはプロジェクトの目標、要件、前提といった「真北」を常に指し示し、方向性を確認する役割を果たす。操舵輪は、現在の進路を継続すべきか、方向転換すべきか、あるいは一時停止すべきかといった意思決定を行うための手段である。そして、目的地の地図は、開発の旅路で得られた成果を記録し、将来的に再利用可能で再現性のある形式で残すことを保証する。

このフレームワークは具体的に三つのステップで構成されている。

第一のステップは「Compass（コンパス）」であり、「Revalidation（再検証）」のプロセスを指す。このステップの主要な目的は、開発が本来の目標や前提条件から逸脱していないかを継続的に確認し、常にプロジェクトの方向性と整合性を保つことである。ここでは、プロジェクトの主要な目標と、副次的で望ましい目標を明確にする。次に、どの要件が必須で、どれがオプションであるかを区別する。現在設定されている仮定に誤りがないか、または無効になっていないかを検証する。また、プロジェクトの制約、開発環境、関係者といった外部要因に変化がないかどうかも確認する。人間とAI/システムとの間で、プロジェクトに対する理解がまだ一致しているか、もし不一致があればその原因を探る。さらに、プロジェクトのスコープが肥大化していないか（スコープクリープ）、矛盾が生じていないか、あるいは最適化の目標が誤っていないかといった、方向性のずれの兆候がないかを常に警戒する。このコンパスによる再検証は、開発プロジェクトの開始時や、文脈の変化、新たな要件の発生など、方向性のずれが疑われるあらゆる時点で実施することで、常に正しい進路を維持することが可能となる。

第二のステップは「Steering Wheel（操舵輪）」であり、「Course Correction（進路修正）」のプロセスを意味する。このステップの目的は、現在の進め方をそのまま継続すべきか、別の方向へ転換すべきか、あるいはプロジェクトを中止すべきかを評価し、適切な意思決定を下すことである。まず、これまでに設定した各仮定がもし誤っていたとしたら、どのような影響がプロジェクト全体に及ぶかを深く考察する。次に、開発中の機能や解決策に対して、既存のツールやライブラリが80%以上の要件をカバーできるものはないか、あるいはこの問題が既存のフレームワークや設計パターン（例：意思決定を記録するADR、提案をまとめるRFC、標準的な設計テンプレートなど）に当てはまるものはないかを検討する。方向転換の選択肢として、異なるアルゴリズムやデータ構造の採用、バッチ処理かストリーミング処理か、CPUかGPUか、ローカル環境か分散環境かといった異なるアーキテクチャの選択、スケッチや機械学習モデル、要約といった異なる表現方法の適用、あるいはインフラ層かアプリケーション層か、制御プレーンかデータプレーンかといった異なるレイヤーでのアプローチも考慮に入れる。これらの選択肢を評価する際には、要件との適合性、構築と保守にかかる複雑さ、価値創出までの時間、そして考えられるリスクや失敗モードといったトレードオフを慎重に検討する。さらに、現在のプロセスが価値に対して過度な負担となっていないか、このアイデアが特定のニッチな問題解決に留まるのか、それともより広く応用可能なのか、といった点も考慮する。最終的に、もし投入する労力が得られる価値を上回り、前提が崩れている場合は中止し、結果が労力に見合うか、あるいは独自の価値を生み出すのであれば続行するという判断基準を設ける。このステップでの次の行動としては、現在のパスを続ける、代替案に方向転換する、既存のソリューションを採用する、またはリスクの高い仮定を検証するために短期間の調査（スパイク）を行う、といった選択肢が考えられる。操舵輪による進路修正は、開発のマイルストーン時や、プロジェクトの振り返り（レトロスペクティブ）の際に、継続、方向転換、停止のいずれかを決定する際に活用される。

第三のステップは「Destination（目的地）」であり、「Reverse Prompt（逆プロンプト）」のプロセスである。このステップの目的は、開発によって得られた成果物を、後から再利用可能で、かつ再現性のある形式で正確に記録することである。具体的には、AIが生成したコードやドキュメントを、後で同じものを再生成できるように、当初の依頼（プロンプト）を明確に再記述する。この再記述には、ソリューションを形作った主要なアイデア、採用されたアルゴリズム、そしてその選択に至った推論の明確な要約を含める。この際、元の表現、構造、順序を正確に保持し、AIによる「親切な書き直し」や「改善」は一切行わないことが極めて重要である。逆プロンプトの要素としては、問題の再記述（1〜2文）、平易な言葉で説明された主要なアルゴリズム、常に満たされるべき不変条件と仮定、入力、出力、エラーケースを明確にしたインターフェースとI/O契約、フラグや環境変数などの設定項目、そして明確な入力と出力のペアを示す受け入れテストや最小限の例が含まれる。このステップでは、High-Level Design（HLD：概要設計）とLow-Level Design（LLD：詳細設計）も作成する。概要設計では、システムが何を解決し、その理由、主要なアルゴリズムのステップバイステップの流れとデータ構造の選択理由、なぜこのアプローチが選ばれ、他のアプローチが却下されたのかというトレードオフ、初期の試みから設計がどのように変化したかの進化の過程、システムのボトルネックや複雑性について記述する。詳細設計では、ファイル、関数、モジュール、データレイアウトなどの構造、入力から処理、出力への制御フロー、エラー処理とエッジケース、設定オプションと具体例、セキュリティと信頼性に関する注意点、性能考慮事項と最適化について詳しく記述する。さらに、機能仕様書や使用方法ガイドとして、具体的な使用例、設定例、一般的なエラーとその解決策、ベンチマークの基準値、システムの限界、将来の拡張ロードマップも作成する。これらのドキュメントを作成する際の重要な要件は、常に概要設計を先に提示し、その後に詳細設計を続けること、単なるコードだけでなくアルゴリズムと推論を強調すること、却下された代替案とその理由を明確に記載すること、そして、コードなしでもドキュメントだけで完結する自己完結型であること、元のコードを正確に保持し、サイレントな変更や書き換えを行わないことである。目的地の地図の作成は、開発サイクルやプロジェクトの終了時に、再現可能なドキュメントや次の担当者への引き継ぎ資料を捕捉するために活用される。

このフレームワークは、システム工学における検証・妥当性確認、アジャイル開発におけるスプリントレビューや振り返り、リーンスタートアップにおける方向転換や継続の判断、アーキテクチャプラクティスにおける意思決定記録、AIプロンプトエンジニアリングにおける再利用可能なプロンプトテンプレート、そしてAIシステムにおける方向性のずれを防ぐための人間による監視といった、実績のある様々な実践に基づいている。航海の比喩を用いることで、これらの実践を覚えやすく、チーム内で伝えやすく、そしてAIを活用したコーディングにおいて日常的に直面する方向性のずれ、整合性の欠如、再利用性の課題に効果的に適用できるシンプルな形にまとめている。このフレームワークは単なる理論ではなく、開発現場で活用できる実践的なプレイブックとして機能する。