これは完成した方法論ではなく、案件ごとに更新している現在の版です。 実務経験の長い方から見れば穴があるはずで、ご指摘は積極的にお待ちしています。

  1. 要求整理と要件固定

    聞き取った要求を整理し、実装可能な要件へ翻訳したうえで、構造化した Markdown に版として固定します。以降の判断はすべてこの版を基準に行います。

    → 要件定義書(版管理)
  2. 仮定の分離

    要件文からは確定できない項目を型別に洗い出し、確認事項の台帳にします。推測で埋めた箇所を、埋めたまま先へ流さないための工程です。

    → 発注元への確認事項リスト
  3. 実装

    着手前に前提と完了条件を問答形式で確定させ、計画を文書にしてから AI へ渡します。実装中に仕様を決め直す必要のない状態を構成して、不毛な手戻りを防ぎます。

    → タスク仕様書
  4. 照合

    完了時に、1 で固定した要件と実装を突き合わせます。どの要件がどの実装で満たされたかを追跡可能な形で残します。

    → 要件⇔実装 対応表

推定で埋めた仮定を、仮定のまま実装へ流さない。

各段は AI コーディングエージェントの Skill として固定しており、案件ごとに手順が揺れません。工程そのものを設計対象として扱っています。

取り返しのつかない操作に承認を挟む

やり直せる操作は AI の判断ループに委ね、やり直せない操作に人間の承認を必須とする仕組みを構築します。具体的には、公開、削除、本番環境への書き込み、外部への送信などが後者にあたります。

この境界は、プロンプトで禁止するのではなく権限の設計で担保します。読み取りだけで完結する作業には、そもそも書き込み権限を渡さない環境の用意を徹底します。プロンプトは上書きされますが、権限のない操作には判断の余地がありません。

AI に入力してよい情報を、その場で決めない

扱う文書には作成時点で機密区分を付与し、区分ごとに AI への入力可否をあらかじめ定めています。判断を作業中の裁量に委ねると、急いでいる時に基準が緩みます。

クライアントから受け取る情報については、公開情報・業務一般・機密・厳秘の4段階で取扱いを分け、匿名化の条件と入力禁止の範囲を文書として定義しています。

却下した選択肢を記録に残す

採用した設計だけでなく、検討して却下した選択肢と、その理由・日付を残します。記録がなければ同じ検討が繰り返され、一度出した結論の根拠も失われるためです。

エージェントのループから、人間の意思決定を外さない。

速度を捨てずに責任の所在を保つための前提だと考えています。成果物の責任が AI に移ることはありません。

Responsible agentic engineering, not vibe coding.

本ページに書いた形式は、このサイトの実装のほか、私が主導権を持つすべてのプロジェクトに適用しているものです。

掲載しているのは進め方の形式のみです。進行中のクライアント案件の要件・設計内容は 本資料に含みません。具体例はすべて、自身で運用している公開物から取っています。