AIコーディングエージェントに「今日中に動くものを」と頼んだとき、実際どこまでの品質に到達できるのでしょうか。ある個人開発の株価予測アプリを実際に調査したところ、テスト252件が全通過、mypy strict通過、TODOコメントゼロという、想像以上に成熟した状態のプロトタイプができていました。何が実現できていて、何がまだ未検証なのかを整理します。

実現できていたこと

FastAPI（Python）＋React（TypeScript）構成で、データ同期→特徴量エンジニアリング→ウォークフォワード学習→過学習防止の検証ゲート→ライブ予測→翌日採点まで、一連の機能が完全に配線されていました。

特に印象的だったのは、単に「動く」だけでなく、過学習対策（アウトオブサンプル検証ゲート）や因果的特徴量設計（未来情報の混入を避ける設計）まで、設計思想レベルで踏み込んでいた点です。

この完成度を支えていた開発プロセス

コードだけを見ると「AIエージェントが自律的に一晩で作った」ように見えますが、実際の開発記録を確認すると、Grok CLI（調査）・OpenCode CLI（実装）・Codex（統合・検証）・ローカルLLM（限定実装）という役割分担されたマルチツール運用でした。特に「LLMに確率そのものは作らせない」という設計境界を、コードだけでなく開発プロセス自体にも一貫して適用していたことが、速度と品質の両立につながっていたと考えられます。

まだ検証できていないこと

一方で、次の点は現時点で未検証です。

• 実装は実質1日分の作業で、実市場での運用実績がまだない
• 過学習防止ゲート（lockbox）が長期的に機能するかは、複数四半期分の運用を見るまで判断できない
• yfinanceという非公式ライブラリへの依存は、個人利用を超えた場面での脆弱性リスクとして残る
• 実装コードが別リポジトリのworktreeに隔離されており、リポジトリ構成としてはやや変則的

テストが全部通っていることと、実運用で長期間安定して機能することは別の話です。この記事の元になった調査でも、「コード品質は高いが、経年による実証はこれから」という留保を明記しています。

まとめ：AIエージェント開発の評価軸

AIに開発を任せた成果物を評価するときは、「動くかどうか」だけでなく、次の観点で見ると実態がつかみやすくなります。

• テストの有無だけでなく、何をどこまでカバーしているか
• 失敗時にどう振る舞う設計になっているか（捏造せず隠す、が典型例）
• 開発プロセスに、AIの出力を無検証で採用しない仕組みがあったか
• 「作った直後」と「運用してから」で評価が変わりうる部分はどこか

1日でここまでの完成度に到達できること自体は驚きですが、それが「もう安心して使える」という意味ではない、という距離感を持って評価するのが実務的です。