⏲️推奨読書時間: 10分
AI開発時代に転生した私は、「願いが叶うようなプログラミング」を信じるのではなく、AIを要件、開発、テスト、ドキュメントという一連の開発プロセスに取り入れています。
多くの人はAIを使ってコードを書くが、最初のステップは要件を入力して、それを直接生成させることだ。
最初は確かに良かった、速くて、効果もまあまあだった。しかし実際のプロジェクトに組み込んだら、問題が浮かび上がった：書き方がプロジェクトと合致しない、権限が漏れている、境界条件を処理していない、例外シナリオを考慮していない、テストも追いついていない。
これらのコードが厄介なのは「動作するように見えて後から修正が難しい」点です。これは完全な文脈に基づいて書かれたのではなく、一時的な説明に基づいて生成されたものです。要件が明確にされず、AIは推測するしかありません。プロジェクトの制約が十分に与えられず、AIは自分の慣習に従って書きます。
そのため、多くの場合、AIがコードを書くのが悪いのではなく、私たちがあまりに早くコードを書かせたからです。要件、境界、計画、テストポイントが準備されていないまま、AIに実装を開始させると、生成が早ければ早いほど、後工程も早くなります。
要件とプロジェクトの文脈を収集
使用して /requirement skill で要件を整理
使用して /grillwithdoc skill で要件、境界、リスクを問い合わせる
軽量技術の実現説明
/TDDスキルを用いて核心ロジックを実装
/テストスキルを用いて単体テスト/コンポーネントテストを補完
/コードレビュースキルを用いてコードレビューを行う
ローカルで実行し、人間による核心フローの検証
/テストケーススキルを用いてExcelを出力し、Transcendプロジェクト管理プラットフォームへのインポートに使用
は/feature-doc-maintainerを使用してドキュメント
を更新します__JHSNS_SEG_63c711ac_47__このプロセスは1から10への直線的なフローに限定されません
主なプロセスは順次進行しますが、要件の質問、技術的な解決策、コードレビュー、ローカルでの検証、およびドキュメントの更新の段階で、前のステップに戻ることがあります問題が見つかれば、前のステップに戻って修正し、早く修正するほどコストが低くなります
AIに要件や提案、コードを書かせるのではなく、最初から始めます。なぜならコンテキストが不十分な場合、AIは見かけ上は完璧に見えますが、実際は一团の結果を返してしまうからです
したがって、最初のステップは要件に関連する情報を整理することです。例えば、元の要件、歴史ドキュメント、類似機能、インターフェースの説明、権限ルールなどです。特に既存の類似機能は非常に重要で、それによりAIはプロジェクトで実際の書き方を参考にできるため、新しい方案を再発明する必要がありません。
コンテキストが明確になった後、次のプロセスを簡単に進めることができますが、最初の情報に誤りがある場合、それは誤った基礎の上で進行する可能性があります。
コンテキストが準備できた後、開発にすぐに進まないでください。まず/requirement skillを使用して要件を一度見直してください。
このステップでは、零散な情報を構造化された内容にまとめるのが主な目的で、機能目標は何か、誰に使うか、核心的なプロセスはどう行われるか、どのようなフィールドや状態が関連しているか、権限ルールは何かなどを整理します。
ここでは確認されていない問題やまだ理解していない点に注意し、まずは TODO でマークしてから、後で確認する人を探す必要があります。 整理が終わったら、基本的に実行可能な要件ドキュメントが作成でき、全体の方向性が明確になります。その後、私たちは grillwithdoc を使って詳細を確定します
ここで出力する際は、plan モードを選択してください
要件ドキュメントがある後、すぐにそれが正しいと決めつけないでください。この時点で、/grillwithdoc スキルを使って再度問い合わせます。
🥚plan モードを使用すると、 対話ボックスがあります を一度ずつ確認することができます
このステップは主に要件がはっきりと記述されているかを確認することです。例えば、境界はどこか、どのシナリオでは実装しないか、例外状況はどのように処理するか、権限とデータ範囲に影響がないか、ボタン制御が完全かどうかなどです。多くの問題は通常のフローでは見つかりませんが、別の角度から問い詰めることで明らかになります。 この/grillwithdoc skillは非常に強力で、基本的にすべての境界と詳細を明確にすることができます。
拷問が完了すると、貴重な要件の詳細を確認したドキュメントが得られます
要件の詳細が確認され次第、実装方法を見ることから始めます
ここでは、最初から重い技術的な提案を書くことをお勧めしません。長すぎると誰も読まず、後でメンテナンスも困難になります。私のやり方は、軽量技術実装説明を出力し、重要な内容を明確に説明するだけです。
このステップの価値は、後続の開発に明確な方向性を持たせることです。特に複数人での協力や要件が複雑な場合、軽量な説明書があると、後でコードを書いたりテストを補ったり、レビューをしたりすることがずっとスムーズになります。
要件が非常にシンプルで、すでに明確な場合、このステップを省略することも可能です。後でドキュメントのメンテナンスを少なくするのも良いでしょう👍
技術実装の説明が確定したら、コードの書き始められます。
/TDDスキル を用いてまず核心ロジックを処理します。AIに一気に書かせるのではなく、まず核心的な行動を分割させ、テストを先に書き、その後にコードを実装するのが良いでしょう。
これをすることの利点は、AIの自由な発想を制限できることです。テストを先に書き、その後のAIの実装はこれらの行動を中心に作成するため、方向を逸れにくいです。
/TDDスキルは、核心的なロジック、状態の変遷、ツール関数、重要なビジネスルールなどの場所に適しています。純粋なページスタイルや非常にシンプルな表示ロジックの場合、TDDを強制的に適用する必要はありません。軽い場合は軽く、プロセスを複雑にしないでください。
TDDが完了したからといって、テストが完了したとは限りません。
TDDは、核心的なロジックが正しく書かれているかどうかに焦点を当てますが、ページのインタラクション、コンポーネントの挙動、例外の分岐、権限の表示/非表示などはおそらくまだカバーされていません。そのため、後で/テストスキルを使用する必要があります。 さらに一巡追加。
テストを行う際は、最終コードと併せて確認する必要があり、要件仕様書だけに基づいて生成するべきではない。そうしないと、テストが多く見えるが、本当に重要な点を測定できなくなる可能性がある。
/Testing Vue Vitest skill これはページ UI の ユニットテスト
コードとテストが書かれた後。この時点で/code review skillを使用できる。 もう一度見直しましょう。
/コードレビューのスキル また、見落としがちな問題を見つけるのに適しています。例えば、重複したロジック、境界処理が不完全、テストでカバーされていない重要なシナリオなどです。
は優先度に応じて品質レポートを出力します
ただし、ここでは注意が必要です。AIレビューは事前チェックにしかなりません。最終的にこのコードがマージされるかどうかは、人間が判断する必要があります。
レビューが完了したら、必ずローカルで実行します。
特にフロントエンド機能については、コードとテストだけを見るのではなく、ページが開けるか、検索のページネーションに問題はないか、新規作成・編集・削除が正常に行われるか、ポップアップの表示が正しいか、エラーメッセージが適切か、権限ボタンが期待通りに表示されるかなど、実際に動かして確認する必要があります。
このステップは純粋な体力作業で、人間による受入検査です。AIはコードを書いたり、テストを補ったり、レビューをしたりできますが、実際に機能を使ってみることはできません。
ローカルでの検査で問題が見つかった場合は、前のステップに戻って修正します。プロセスが8段階まで進んでいるからといって、無理に次に進めないでください。
ローカルでの検査が通過したら、テスト用例を整理し始めます。
ここでは/testcase skill を使ってテスト用例のExcelを出力します。これは最初の要件に基づいて生成されるだけでなく、要件ドキュメント、技術実装説明、最終コードの変更、既存のテストポイント、ローカルでの検査結果を合わせて生成されます。
このように作成された用例は、実際の機能に近づきやすく、見た目は完整に見えるものの、重点を測定できない内容を書きにくくなります。
今回は Excel を Transcend プロジェクト管理プラットフォームにインポートしています。または、テストに渡して評価してもらっています。
最後のステップはドキュメントの更新です。
ここでのドキュメントは、リポジトリ内で機能と強く関連するものを主に指し、機能の説明、権限ルール、インターフェースの変更、操作手順、既知の制限、テストの説明などです。正式なドキュメントを補完するためではなく、最終的な実装を記録するためです。
多くの場合、ドキュメントは要件段階で停止してしまい、コードが変更された後でもドキュメントが追いつかないことがあります。時間が経つにつれて、次回同じ機能を変更する際には、再度理解し直す必要があります。
だから、私は最後に /feature-doc-maintainer を使って同期し、最終的な実装と重要な説明を追加します。これにより、今回の作業の成果はコードに留まらず、後の人（AI）が引き続き使えるようになります。
正しいことをする方が、正しくすることよりも重要です。
このプロセスは多くのSkillを使っていますが、核心的な判断は完全にAIに任せられません。
AIは私たちを助けて情報を整理し、コンテンツを生成し、テストを補完し、初期審査を行うことができますが、要件の選択、技術的な判断、テストの評価、最終的な承認は人に任せなければなりません。
要件段階：方向が成立するかどうか、どの範囲を実装し、どの範囲は先延ばしにし、どの問題は必ず製品や責任者に確認する必要があるかを判断する必要があります。AIは問題をリストアップできますが、選択を代行することはできません。
コードとテストフェーズ：コードがプロジェクトの現状に合致しているか、変更コストが受け入れ可能か、テストが本当に主要なリスクをカバーしているかを判断する必要があります。コードが組み込めるかどうか、テストケースが価値があるかどうかは、最終的には人間が判断します。
したがって、このプロセスはAIが人間を置き換えるのではなく、人間が繰り返し整理、補完、チェックなどの作業から解放され、より重要な判断と選択に集中できるようにすることです。AIは材料を準備し、人間はそれらが正しいか、使用可能かどうかを判断します。
このプロセスの最大の変化は、特定のステップが突然どれだけ速くなったかではなく、全体のプロセスがより安定したことです。
/requirement skill と */grillwithdoc skill*、多くの境界、権限、例外シナリオは開発前に明らかにしておくことで、コーディング中に要件を追加するのを避けることができます。
各ステップに明確な入力と出力があり、AIが自由に振る舞うのではなく、要件、提案、コード、テスト、ドキュメントがつながりやすくなり、結果もより簡単に確認できます。
問題が早く発見されるほど、修正コストは低くなります。要件と提案の段階で解決できる問題は、コードを書き終わった後に修正するのではなく、その時点で修正するべきです。
テストは最後の臨時の補完ではなく、要件、実装、コード変更、ローカルでの検証結果に基づいて生成されるため、より実際のリスクに近づきます。
/testcase skillを通じて Excelを出力し、Transcendにインポートしたり、テスト評価に渡したりすることで、それがローカルファイルだけではなくなる。
最後に/feature-doc-maintainerで最終的な実装、権限ルール、インターフェースの変更、既知の制限を補足し、後続のメンテナンスを容易にし、AIがコンテキストを理解し続けることを容易にする。
人は方向の確認、結果のフィルタリング、最終的な受領を担当する。
要件：Planモードで最初に使用し、直接実行しない
要件フェーズでは、Planモードを使用し、AIが最初に質問し、境界を分割し、TODOリストを作成する。
この段階ではコード生成を急がないこと、方向性や範囲、実施しない項目を先に確認することが重要です。
コード：まずOpus 4.7で計画を立て、次にComposer 2.5で実行
複雑な要件はまずOpus 4.7で方案を作成し、変更範囲、核心的なロジック、リスクポイントをリストアップします。
方向性が問題ないことを確認したら、Composer 2.5で計画に従ってコード修正を実行します。
これにより、実行モデルに直接コードを変更させるよりも安定し、変更範囲をより容易にコントロールできます。
テスト：まず核心的なパスをテストし、次に境界シナリオを追加
最初からテストを完璧に追求しないこと。
まずAIで核心的なプロセスをカバーし、主パスが動作することを確認したら、権限、例外、空データ、検索分页、ポップアップの反映などの境界シナリオを追加します。
テストケースも人間によるフィルタリングが必要で、価値のないものは無理に残さないこと。
ドキュメント：最後に更新し、最終的な実装に基づいて
ドキュメントは早すぎる段階で完成させないこと。
前の要件、コード、テストは調整されるため、ローカルでの検証とレビューの後、/feature-doc-maintainerで更新するのが良い。
最終的な実装、権限ルール、インターフェースの変更、既知の制限に重点を置き、重いマニュアルにならないように書くこと。
最初の問題に戻って、なぜこの実践を開発プロセスに組み込むのか？
単純にAIにコードを書かせるだけでは、少しだけ効率の問題を解決できるだけです。本当に開発を遅くするのは、コードを書くのが遅いだけでなく、要件が明確でない、境界が十分に考慮されていない、テストが遅れて行われる、ドキュメントが追いつかないことが多いです。問題は何もしていないことではなく、各ステップで前のステップのギャップを埋めることです。
このプロセスの核心は自動化ではなく、コントロールです。各ステップには入力、出力、チェックポイントがあり、いつでも人間が介入して確認することができます。AIの能力が強ければ強いほど、このようなプロセスでそれを引き受ける必要があります。
最後に達成すべきことは、AIが私たちに開発を代行することではなく、AIが安定して開発に参加することです。要件に根拠を持たせ、提案に制約を設け、テストにフィードバックを与え、ドキュメントに蓄積を持たせることで、効率化は一時的なものではなく、継続的に再利用できるものになります。
このプロセスで主に使用されるSkillは以下の通りです：
| Skill | 役割 |
|---|---|
requirement-analysis |
要件を整理し、零散な情報を実行可能な要件文書にまとめる |
grill-with-docs |
要件の境界、例外シナリオ、権限とリスクを問う |
tdd |
テスト駆動開発で核心的なロジックを実装する |
testing-vue-vitest |
Vue 3 + Vitest の単体テストとコンポーネントテストを補完する |
code-review |
コードレビューを行い、事前に品質とリスク問題を発見する |
diagnose |
複雑なバグや性能問題が発生した場合、再現、仮説、検証、修正、再検証のフローに従って問題を特定します。 |
testcase-excel |
テストケースのExcelを作成して、テスト管理プラットフォームにインポートしやすくする |
feature-doc-maintainer |
最終実現に基づく機能ドキュメントの更新 |
これらの Skill を自分のプロジェクトに組み込みたいなら、私が整えた Git リポジトリを参考にしてください。
これらの Skill は固定の答えではなく、さらに調整できるプロセスのテンプレートに近いものです。実際に実装する際には、チームのプロジェクト構造、テスト規範、ドキュメント習慣に合わせて一度改造することをお勧めします。
このコンテンツは慣性聚合(RSSリーダー)によって自動集約されています。参考としてご覧ください。 原文出典 — 著作権は原著者に帰属します。