背景
きっかけは、チームリードとの何度かの 1 on 1 ミーティングでした。彼は私が AI ツールをどう使い、個人用の Harness をどう構築し、AI Coding のワークフローをどう組み立てているかに興味を持っていました。というのも、私が要件を速く・正確にこなしており、すでにいくつかのプロジェクトで主担当を務めていたからです。そこでこの機会に、日々の AI ワークフローを整理してみることにしました。現在、私のグループでは既存のバックエンドビジネスロジックを保守しつつ、主に Agent 開発を担当しています。
以前、関連するワークフローを Xiaohongshu で共有したことがあります。当時の文脈としては、GPT-5.4 や Opus 4.6 は、正確なコンテキストと妥当な制約を与えればすでにタスクをうまくこなせるというものでした。Harness Engineering の台頭により、「制約を追加することで強力なモデルをより良くコントロールできる」と皆が気づいたのです。
たとえば Superpowers のような Skills は比較的ヘビーな実装で、主に Spec と TDD を軸にしており、タスクの整理や推進を楽にしてくれます。
しかし、これにはデメリットもあります。最もわかりやすいのは「Token の消費が非常に速い」ことです。Superpowers のような Skills には、モデルの次のアクションを制約するための Workflow が多数含まれています。全体から見ればあるステップが不要になっている場合（たとえばコンテキストが十分でそのまま実装に入れる場合）でも、モデルはあらかじめ決められたプロセスに沿って実行を続けてしまうことがあります。
新しいモデルのリリースに伴い、こうした非常にヘビーな Skills をほぼ使わなくなったと共有する開発者を多く見かけるようになりました。主な理由の一つは、モデルの能力向上により、これまで有用だと思っていた制約やプロセスの一部が、モデルにとってノイズになりつつあることです。たとえば OpenAI が Astra をリリースした際、不要な Skills やシステムプロンプトを整理してモデルの利用体験を向上させる方法を紹介するブログ記事をわざわざ公開していました。
そこで本記事では、ここ数ヶ月の実践をもとに、現時点で私に有効な方法をいくつか共有し、さまざまな Agent を活用して日々の開発効率をどう高めるかを考察します。
1. よく使う Skills と Prompts
現在の私のツール分担は以下の通りです。
コーディング実装には主に Codex + GPT-5.6 Sol を使い、計画立案には Astra を使っています。Astra のリリース前は、計画作業は主に GPT-5.6 Sol Max に任せていました。
シンプルな要件には pi + DeepSeek V4 Flash で実装し、設計案の敵対的レビューや Code Review は主に Claude 5 Fable に担当させています。個人プロジェクトでは、Web 版の GPT-6 Pro をメインの設計にも使っています。
よく使う Skills
- think: tw93 の Skill で、主に設計案のすり合わせやブレインストーミングに使います。
- grill me / grill with docs: 主に要件の明確化に使います。継続的な質問を通じてゴール・制約・トレードオフを明らかにし、開発プロセスの必要に応じて ADR や CONTEXT.md として落とし込みます。初期のすり合わせで見落としていた課題を掘り起こすのに役立ちます。
- implement: grill と併用するもので、Matt Pocock の Skills スイートの一部です。明確になった計画や Issue の実装に使います。
- ponytail: AI による過剰設計を整理し、Review の難易度を下げるために使います。GPT-5.6 Sol は過剰設計しがちなので、私は頻繁に使っています。
- handoff: 現在のコンテキストをファイルにまとめ、新しいセッションでの作業継続を容易にします。通常は Codex から Claude Code や pi agent へ引き継ぐ際に使います。
- check: コードレビュー用で、MR を提出する際に使います。
- 業務や個人開発から蓄積した Skills: 主に再利用可能なプロセス SOP（例：E2E テスト）です。日常業務で同じプロセスを 3 回以上繰り返すなら、Codex に Skill として整理させ、次回から直接再利用できるようにすることをおすすめします。
よく使う Prompts
最近は自分で長文の Prompt を書くことはほとんどありません。必要なときは、たいてい Codex に整理させます。たとえば、何ラウンドも議論した後に、現在のコンテキストを GPT Pro に渡して設計させたい場合は、まず Codex に完全な handoff 用 Prompt を生成させます。
それ以外では、以下のような非常に短い Prompts を頻繁に使います。
これらは時に「一言千金」の効果を発揮します。私はこれをモデルの「思考のショートカット」と捉えています。
魔法の呪文ではなく、人間の知識の中で高度に標準化された方法論です。学習段階でモデルは関連する論文・コード・設計書・議論を大量に見ているため、数百行の Workflow を手書きする必要はなく、「どの思考法を採用するか」を伝えるだけで十分なことが多いのです。実践で非常に効果的だったプロンプトをいくつか紹介します。
- First Principles（第一原理）: 既存の解決策に沿って最適化を続けないこと。この問題は本来どう解くべきかを問い直すこと。たとえばインターフェースが遅い場合、こう伝えます。
「Redis キャッシュを追加する」という既定の解決策に基づいて設計を続けないでください。第一原理から、なぜこのインターフェースが遅いのか、そして最小限必要な解決策は何かを分析してください。
するとモデルの焦点は「Redis をどう設計すべきか」から、次のように移ります。
ボトルネックは SQL、ネットワーク、シリアライズ、ロック競合、それとも再計算にあるのか？SQL にインデックスを追加すれば解決するなら、なぜ Redis を導入するのか？
この種の Prompt は「問い自体が間違っているかもしれない」と疑う場面に適しています。
- Adversarial Review（敵対的レビュー）: 私の設計案を正当化する理由を探さず、それが間違っていると証明しようとすること。
普通の頼み方はこうです。
この技術設計に問題がないか確認してください。
これを次のように変えます。
この設計案に対して敵対的レビューを行い、核心的な前提を覆せる反例を優先的に見つけてください。
あなたの設計案が「重複リクエスト対策に分散ロックを導入する」だと仮定すると、モデルはロックのタイムアウト設定方法を教えるだけでなく、こう問い始めます。
重複リクエストに本当に排他制御が必要か？インターフェースの冪等性で解決できないか？ロックサービスがダウンしたらどうなる？ロックが切れたのにビジネス処理が終わっていなかったら？ローカルな問題を解決するために、新たな分散障害ポイントを持ち込んでいないか？
この種の Prompt は、設計レビューや Code Review に特に適しています。
- Ablation Experiments（アブレーション実験）: システムが改善しても、追加したすべてが有用とは限らないこと。
たとえば、一度に 3 つの最適化を行ったとします。
インデックス、Redis キャッシュ、バッチクエリを追加した後、インターフェースのレイテンシが 800ms から 100ms に低下した。
このとき、直接こう尋ねます。
これら 3 つの最適化についてアブレーション実験を設計し、本当の効果がどこから来ているのかを特定してください。
モデルはさまざまな組み合わせを軸に対照群を設計し、Baseline から始めて、インデックスのみ、インデックス＋キャッシュ、インデックス＋キャッシュ＋バッチクエリなどを比較します。
最終的に、こう判明するかもしれません。
インデックス追加だけでレイテンシは 800ms から 120ms に下がっており、残りの 2 つの複雑な施策の寄与はわずか 20ms だった。
これで、どのコードを残す価値があり、どの複雑性が不要かもしれないかが明確になります。
- Occam's Razor（オッカムの剃刀）: 効果が同等なら、前提が少なく複雑性の低い解決策を優先すること。
たとえば、Agent が次のような設計を出してきたとします。
Kafka + Redis + 分散ロック + ステートマシン + 定期補償。
こう一言添えます。
オッカムの剃刀を使ってこの設計を見直し、要件を満たす前提で必須ではない仕組みをすべて削除してください。
多くの場合、最終的にこう結論づけます。
今回のシナリオは単一データベースへの書き込みだけなので、1 つのトランザクションとユニークインデックスで十分です。
この一言は現在の Coding Agent に対して特に有効です。モデルは「網羅性」のために過剰設計しやすいからです。
- High Cohesion, Low Coupling（高凝集・低結合）: コードの責務と境界を再確認すること。
たとえば OrderService がすでに 2000 行あると気づいたら、こう尋ねます。
高凝集・低結合の原則に従って OrderService の責務境界をレビューしてください。分割のための分割はしないでください。
モデルは通常、こう確認し始めます。
なぜ注文サービスが在庫、クーポン、SMS、決済、レポートを同時に扱っているのか？どのロジックが注文ドメイン自体に属し、どれが安定したインターフェース経由で他のモジュールに委ねるべきか？
これは単なる「ファイル分割」ではなく、モジュール化、情報隠蔽、依存方向、責務分担に関する一連の判断を呼び覚まします。
そのため、私はもうこういう書き方はほとんどしません。
Step 1 要件を分析、Step 2 前提を確認、Step 3 代替案を探す、Step 4...
成熟した方法論の多くは、すでにモデルが学習済みです。私は直接こう伝える方を好みます。
第一原理から再分析し、現在の設計案に敵対的レビューを行ってください。核心となる仕組みはアブレーション実験で検証すること。設計はオッカムの剃刀に従い、コードは高凝集・低結合を維持してください。
この数十文字の裏では、実は 5 つの異なる認知的アクションが指定されています。
問題の再定義 → 前提への攻撃 → 寄与の検証 → 複雑性の削除 → システム境界の整理。
これが、私の考える新モデル時代における Prompt Engineering の変化でもあります。完成された固定の思考プロセスをモデルに書くよりも、正確な方法論で「どう考えるか」を伝え、その上で現在のタスクに本当に必要な制約だけを補足する方が良いのです。
2. 日々の開発ワークフロー
要件を受け取ったら、まずは PRD、議事録、チャット履歴、ユーザーフィードバックなどの関連コンテキストを Agent に渡し、grill を使って要件をすり合わせます。
これらの資料は、完全で一貫した要件ではないことがほとんどです。PRD が更新されていない、会議で制約が追加された、チャットで優先度が調整されたといったことがあります。私自身の要件理解にも、暗黙の前提が含まれているかもしれません。
Agent にはチームの Wiki や既存コードと合わせてこれらの資料を理解させ、継続的な質問を通じてゴール・境界・実装に影響するトレードオフを明確にさせます。その場で答えられる質問もあれば、PM や関係者に確認しに戻る必要がある質問もあります。
ここで私は一つの基準を持っています。「残っている疑問が、実装方針や受け入れ結果を大きく変えない段階」になったら、開発を開始します。
すべての実装詳細を事前に計画させることは求めません。そうしないと、要件すり合わせ自体が非常に重いプロセスになってしまうからです。
すり合わせ後の結論は Spec や CONTEXT.md に落とし込みます。主に今回解決する問題、スコープ、重要な意思決定、受け入れ基準を記録します。これにより、後続の実装・レビュー担当 Agent も同じコンテキストを共有でき、過去の会話をすべて読み返す必要がなくなります。
設計が決まったら、タスクの複雑度に応じてメインの Agent に実行方法を判断させます。シンプルな要件はそのまま実装し、複雑な要件は境界が明確で独立して受け入れ可能な Issue に分割します。独立して進められる部分だけをサブエージェントに渡し、別々の worktree で並行開発させ、最後にメインの Agent が統合します。
コーディング Agent には先にテストを書かせます。完了したと思ったら、タスクの複雑度に応じて他の Agent を導入し、交差する敵対的レビューを行います。見つかった課題はメインのコーディング Agent（つまり Codex）に一括でフィードバックし、修正・再検証させます。
自分自身で Review する前にも、E2E テストを実施します。
現在は生成されたコードをすべて 1 行ずつ読むことはせず、主にテスト結果とコアなビジネスロジックを確認します。ここには重要な前提があります。各 MR のスコープが十分に小さく、開発が進むにつれて完全なビジネスパスが段階的に検証されていることです。
小さな MR にすることで、毎回理解・判断が必要な変更をコントロール可能な範囲に収めます。E2E テストは、それらの変更を実際のビジネスプロセスに組み込んだときに耐えられるかを確認するのに役立ちます。手動 Review では、ビジネスロジックの確認と、既存のテスト結果がこのリリースを支えるのに十分かどうかの判断に集中します。
3. Agent フレンドリーな E2E テスト環境の作り方
AI はすでにテストケースを書くのが非常に得意で、Bugfix 一つに数百行のテストを書くことも珍しくありません（特に 5.6 sol）。テストを多く書くこと自体は問題ではありませんが、デプロイ・リリース後に予期せぬエラーに遭遇することが依然としてあります。
私の実践において、核心的な課題は「Agent に E2E テスト環境を提供しておらず、コーディングや自己テストの段階でこうした問題を発見する機会を与えていない」ことでした。
もしそうした環境を構築し、Agent がテスト環境の実際のエントリーポイントからタスクを実行し、ユーザーに必要な結果まで一通り確認できるようになれば、AI が書いたコードを実システムで動かすことに自信を持てます。
実際の開発では、私たちのビジネス向けに E2E 開発テスト環境を一式構築しました。Agent はデータベーステーブルやログを簡単に参照し、マシンに接続してトラブルシューティングできます。
構築プロセスの本質は、私が日常的に行っている開発時の自己テスト手順を Agent に抽出させ、散在していたツールや機能を統合することです。ツール化できる機能は MCP や CLI にし、再利用可能なプロセスは Skills に書き込みます。
確かに初期の手間はかかりますが、面倒を恐れないでください。一度作ってしまえば開発速度は大幅に上がり、手戻りや本番障害の可能性が減り、「AI が書いたコードで事故が起きないか」と一日中心配する必要もなくなります。
Agent フレンドリーな E2E テストに向けて、私は主に 4 つのことを行いました。
- Agent に環境を把握させる: テスト環境のワンクリック起動、テストデータ作成、現在のバージョン・テストアカウント・権限の明確化、クリーンアップやリセット機能の提供など。
- Agent にビジネスシステムを操作させる: ブラウザ、API、CLI 経由で実際のビジネスプロセスを実行させる。
- Agent が DB テーブルやログを簡単に参照できるようにする: 読み取り専用の DB MCP で保存結果を確認し、ログシステムの Skills や Trace クエリで問題を特定する。
- 面倒だが安定したプロセスを再利用する: 安定した操作をスクリプト化し、エントリーポイントやトラブルシューティング方法を Skills にまとめて、手動介入や対話の繰り返しを減らす。
これらの取り組みを踏まえ、現時点で有効だと感じている方法をいくつか紹介します。
- ブラウザ自動化: ビジネスシステムでブラウザ操作が必要な場合は、オープンソースのブラウザ ego lite をおすすめします。使いやすく高速です。pi agent + DeepSeek V4 Flash と組み合わせると、比較的短時間でテストを完了でき、テスト時間を削減できます。
- 操作を CLI に統一する: 再利用可能な Skills、設定済みの MCP、作成したスクリプトを統一されたテスト CLI に統合し、環境チェック、データ準備、シナリオ実行、結果確認、クリーンアップの機能を提供します。これは社内効率化ツールにもなり得ます。現在、私はこれを一式 CLI にしており、問題発生時のトラブルシューティングにも便利です。
- ツールを直接受け入れに活用する: DB クエリは状態確認に、ログや Trace は失敗原因の説明に使いますが、期待される結果はあくまでビジネス契約から導く必要があります。システムが返した値を見たからといって、それを正しいと Agent に推測させてはいけません。複雑なビジネスロジックの下では、システムが一見妥当だが実際には仕様に合わない結果を完全に返しきってしまうことがあります。ツールは証拠を得るための支援であり、正解を定義するものではありません。
- プロダクト自体が Agent の場合は回答品質も確認する: テスト対象のプロダクト自体が Agent である場合、ビジネスプロセスが通るかどうかだけでなく、回答の品質も考慮する必要があります。いわゆる Agent Eval ですが、ここでは詳しく触れません。
4. AI が書いたコードのレビュー方法
これまでのセクションでは AI に高品質なコードを書かせる方法を共有しましたが、最終的にビジネス要件の主責任者は開発者自身です。
Review なしでは、大規模なシステムは容易に問題を抱えます。
深夜に On-call で叩き起こされ、原因が AI の書いたコードだったとわかる事態は避けたいはずです。
Review について、現在の私の主な実践は以下の通りです。
- まず受け入れ基準を見て、次にテスト結果を見る: Agent が提示した受け入れ基準を確認し、先ほどの E2E テスト結果と照らし合わせて、期待が満たされているか、漏れはないかを確認します。テストがいくつ通ったかだけでなく、それらのテストがこの要件で本当に重視していることを検証しているかを見ます。
- ビジネスパスに沿って実装を読み、ハイリスク部分に集中する: 主に権限、状態変更、並行処理、リトライ、データ整合性、マイグレーションやロールバックなどのハイリスク部分を確認します。安定したパターンの CRUD は時間をかけません。今では一部は見ることすらありません。
- 新規追加された抽象化や仕組みを重点的に確認する: 新しく追加された抽象化や仕組みについては、オッカムの剃刀のような考え方を用いて AI に再度レビューさせます。本当に必要か、もっとシンプルな実装はないか、局所的な問題に対して複雑性を持ち込みすぎていないか。
- MR が多い場合は専用 Review Bot の構築を検討する: グループ内に MR が多い場合は、交差レビューを担う専用 Review Bot を設計できます。前述の pi agent / Claude Code を直接呼ぶ敵対的レビューとは異なり、Git の変更情報と事前設計されたレビュープロセスを組み合わせ、MR に特化した再現性のあるレビュー能力を形成することに重点を置きます。
5. まとめと考察
現在の開発における私の最大のボトルネックは、Review の速度です。
Agent は複数のタスクを同時に進められますが、私がビジネスを理解し、設計を判断し、成果物を確認する速度は比例して上がりません。ただたくさん書かせれば、レビュー待ちのコードが積み上がるだけです。
そこで次に改善したいのは、繰り返しの課題が私の手に届く前に発見・修正されるようにすることです。
型チェック、テスト、ビジネスアサーションで発見できる課題は、できるだけ開発中に Agent 自身に処理させます。私の判断が必要なものは、「要件を正しく理解しているか」「主要なビジネスロジックが成立しているか」「この変更で未検証のリスクは何が残っているか」に集中させます。
専用 Review Bot はこうしたことを助けてくれますが、その価値はコメントの数ではなく、有効な課題の見落としや手動作業の負担をどれだけ減らせるかに依存します。
これにより、Harness に対する私の理解も徐々に具体的になってきました。Agent には正しいコンテキストを与えるだけでなく、タスクを実行できる環境と、結果を判断するための基準も必要なのです。
日々の自己テストで繰り返していた操作を CLI、スクリプト、Skills にまとめ、Agent 自身がシステムを実行し、結果を確認し、失敗の証拠を見つけられるようにしました。今後の類似タスクでもこれらの機能を使い続けることができ、徐々に他のメンバーにも共有して再利用してもらえます。
同時に、このワークフローは定期的に「引き算」をする必要があります。
一部のステップは、特定の世代のモデルの弱点を補うためのものです。モデルが変われば、そのステップのメリットは再評価すべきです。シンプルなタスクはそのまま実行し、複雑なタスクには計画・分割・交差レビューを追加します。たとえば Astra のアップデート後、私は AGENTS.md の過度に厳格な制約をいくつか削除しました。モデルは進化し、私たちのワークフローもそれに合わせて進化させる必要があります。
もちろん、テストや Review は不確実性を減らしますが、人間が正しい受け入れ基準を与える必要は変わりません。コードとテストが一致していても、両方そろって要件を誤解している可能性があります。E2E テストは選択された環境やシナリオでの挙動しかカバーせず、本番環境のトラフィック、同時接続数、データ分布が新たな問題をもたらすこともあります。
私のように働き始めたばかりの開発者にとって、業務を通じてより専門的な知識を学びたいという思いは依然としてあります。しかし、AI は自ら罠に踏み込む機会を確かに減らしてしまいました。問題を経験し原因を調査することで得られていた貴重な経験が、今では AI のこんな一言に変わってしまうことがあります。
「間違っていました。今すぐ修正します。」
だからこそ、
私は現在、日々の開発時間の一部を学習と振り返りに充てながら、「AI 時代の R&D メンバーに本当に必要な能力とは何か」を考えています。
本記事は、入社後数ヶ月で自分の業務の中で少しずつ模索してきた手法をまとめたものです。適用範囲や不足点は、まだ探求中です。
まずは皆さんも、普段よくやっている自己テストのパスを一つ選び、Agent に単独で実行させてみて、証拠を残し、有効だったステップを蓄積してみてください。
会社の機密保持要件により、記事に載せられない詳細も多くあります。本記事が玉を引くためのレンガ（抛磚引玉）となれば幸いです。皆さんの実際の開発における良いプラクティスをぜひ聞かせてください〜
