開発記録（第7回）。AI に日本株の売買判断をさせる投資システム investTool を個人で開発しています。全体像は目次記事にまとめています。
- 調査・設計・レビューを Claude、実装とテストを Codex に分けて開発しています
- 段階3（リスク管理・通知・仮想売買）のレビューで28件の指摘が出て、半分の14件が「設計書にあるのに実装されていない」ものでした
- 「設計書に書いてあるから伝わるはず」と考えるのをやめ、依頼の中で完了の条件を具体的に書く形に変えました
やりたかったこと
1つの AI に設計から実装まで任せると、仕様を決めた本人が実装を確かめることになり、見落としに気づきにくくなります。そこで、2つの AI に役割を分けました。
| 担当 | 役割 |
|---|---|
| Claude（Anthropic） | 調査、要件の整理、設計、レビュー |
| Codex（OpenAI） | 実装、テスト |
| 運営者（人） | 方針の決定、各段階の承認 |
AI 同士はチャットで直接やり取りしません。すべて設計書を通します。実装を直す必要が出たときも、まず設計書を直し、その設計書を参照する形で依頼します。口頭の指示だけで直すと、次に設計書を読んで作業したときに実装が元に戻ってしまうためです。
手順：レビューの指摘を ID で管理する
レビューで見つかった指摘は、R-01 のように ID を振って1つの文書にまとめます。1件ごとに次の項目を書きます。
| 項目 | 内容 |
|---|---|
| 区分 | 実装漏れ／設計を修正／不具合／実装品質 |
| 優先度 | 高（合格判定に直結）／中／低 |
| 変更してよい範囲 | 触ってよいファイルの一覧 |
| 参照 | 仕様の正になる設計書の場所 |
| 受入条件 | 何を満たせば完了か。番号ごとに独立した条件 |
依頼は「R-03 と R-07 に対応してください」のように ID で行います。Codex から完了の報告が来ても、そのまま完了にはしません。Claude が実装と突き合わせて確かめてから、状態を「完了」にします。
つまずいた点と解決
1. 指摘の半分が「実装漏れ」だった
- 症状
- 段階3のレビューで28件の指摘が出て、14件が「設計書にあるのに実装されていない」ものだった
- 原因
- 依頼の中で名指ししなかった項目は、設計書に書いてあっても実装されなかった
- 対処
- 受入条件を、参照先を読まなくても何をすれば完了かが分かる粒度で書く
Codex は、依頼された範囲で最小の変更をするように指示しています。範囲を広げすぎないための決まりですが、裏返すと、依頼に名指ししなかった項目は実装されません。設計書には書いてあっても、「その設計書を読んで全部を満たしてください」という依頼にはなっていなかったのです。
「設計書に書いてあるから伝わるはず」と考えない。受入条件は、参照先を読まなくても何をすれば完了かが分かる粒度で書く。この一文を、2つの AI が共通で読む開発ルールの文書に明記しました。
2. テストが通っても、確かめたいことを確かめていなかった
- 症状
- バックテストと仮想売買の結果が一致するかを確かめるテストが、実装を壊しても通った
- 原因
- テストのデータでは期間中に損切りの価格が一度も動かず、比べる値が常に同じだった
- 対処
- 受入条件に「実装を一時的に壊すと落ちることを確かめてから報告する」を加えた
最初の指摘（R-01）は、「バックテストと、仮想売買の毎日の処理で、同じ期間を動かしたら結果が一致するか」を確かめるテストがない、というものでした。これは investTool でもっとも壊れてはいけない部分です。
テストは追加されましたが、確かめると、損切りの価格を書き込む処理をわざと壊してもテストがすべて通りました。テストのデータが「横ばいの後に下落」で、損切りの価格が引き上げられる場面が一度もなかったためです。
そこで次の条件を足しました。
- テストの中で、損切りの価格が少なくとも1回引き上げられること
- 実装をわざと壊して、テストが落ちることを確かめてから報告すること
| わざと壊した箇所 | 結果 |
|---|---|
| 損切りの列に、当初の損切りの価格を書く | 落ちる |
| 再計算の結果にない古い記録を消さない | 落ちる |
| 約定の価格を1円ずらす | 落ちる |
| 建玉の状態を常に「保有中」にする | 落ちる |
| 資産の推移を1円ずらす | 落ちる |
最初の2件の指摘（R-01・R-02）は、どちらも「テストがない」でした。しかも、仮想売買とバックテストの一致、注文の指示を作る処理という、もっとも分岐が多く壊れてはいけない箇所です。テストを受入条件に含めない依頼では、テストは書かれないと考えたほうがよい、というのが実感です。
実際にどう使っているか
28件はすべて是正を終えました。そのうち9件は、実装が一巡した後の稼働確認の準備や、稼働確認の1日目の通知から見つかったものです。その話は次回に書きます。
なお、最後の2件（R-27・R-28）は、Codex の利用枠が上限に達したため、Claude が実装しました。役割は分けていますが、固定ではありません。
AI に実装を任せるときの落とし穴は、「仕様書がある」ことと「それが実装される」ことが別の問題だという点でした。仕様書を書いた後の依頼の粒度と、完了の確かめ方まで決めて、はじめて分担が回るようになりました。
この記事の内容に近い書籍
※ Amazon のアソシエイトリンクを含みます。
- 『実践Claude Code入門』（西見公宏、吉田真吾、大嶋勇樹、Kindle版）
Claude Code を開発に使うときの考え方。この記事の、AI に役割を分けてレビューさせる話と近い本です - 『Claude CodeによるAI駆動開発入門』（平川知秀、Kindle版）
Claude Code の使い方を、アプリを作りながら説明する本です
前回：売買ルールを8種類試して、すべて合格基準に届かなかった記録｜バックテストの結果と、先に進んだ理由
次回：直しても再発する表記の不統一と、安全装置が別の機能を壊した話｜稼働確認の1日目に見つかったこと
当サイトは情報提供を目的としており、投資助言を行うものではありません。掲載している売買記録は仮想売買（ペーパートレード）であり、実際の取引の結果ではありません。投資判断はご自身の責任で行ってください。詳しくは免責事項をご覧ください。
