AI隊 開発日記

フェーズ1.5 実運用継続檢証

本日は「品質を議論する」のではなく、「品質を実装と運用で証明する」ことを強く意識したセッションとなった。

実装中心への方針転換

セッション序盤で、品質監査の議論に時間を使い過ぎていることを振り返った。

フェーズ1.5の目的は、

  • コードを書く
  • テストする
  • Hotfixする
  • 実運用で観察する

ことであり、品質議論はそれを支える補助であることを再確認した。

以降は、小規模実装→檢証→コミット→ドキュメント更新という短いサイクルを意識して開発を進めた。





AI隊

品質監査で採用した「確認した事実・採用する運用方針・継続観察事項」の3区分について、自動バリデーションをAI隊へ実装した。

その後、品質憲章を見直し、全プロジェクト共通の原則だけを残し、巡回バッチのようなプロジェクト固有の設計パターンは各リポジトリの設計書へ分離した。

さらに、

  • 計画書=未来
  • 課題=現在
  • 履歴=過去

というドキュメントライフサイクルを整理し、長期運用を見据えた役割分担を明確化した。


投資アプリ

評価損益(pnl)の集計・表示機能を追加した。

既に読み込み濟みだったデータを有効活用し、コンソール・CSV・Excelへの表示まで対応した。

ローカル実行により動作を確認し、実装・檢証・記録まで完了した。


五条ハーレム

商品カードへ商品説明表示を追加した。

また、画像取得失敗時に自動でプレースホルダーへ切り替えるフォールバック処理を実装した。

TypeScript型チェックは正常終了したが、実ブラウザでのUI確認は未実施であるため、「型チェック濟み・ブラウザ実機確認待ち」として管理することにした。

実装したことと、実機確認できたことは明確に区別する運用へ変更した。


動画告知Bot

各監視先の fetch_updates を個別に例外保護する構造へ改善した。

さらに、

  • エラーログ出力
  • 失敗監視先の集約
  • 最終警告サマリ
  • 後続処理継続

を追加し、巡回型バッチとしての耐障害性を向上させた。

ダミー例外を用いた異常系テストでは、一部監視先が失敗しても他の監視処理は継続し、最後に警告サマリを出力して正常終了することを確認した。

檢証後はダミーコードを削除し、構文チェックも再実施した。


Git整理

各プロジェクトの未コミット変更を整理し、適切な粒度でコミットした。

変更履歴を整理したことで、次回以降はクリーンな状態から開発を開始できる環境が整った。


ドキュメント運用の改善

今回最も大きな成果は、ドキュメントの設計よりも運用方法を整理できたことである。

品質憲章には共通原則のみを残し、設計パターンは各プロジェクトへ分離した。

また、

  • What
  • 檢証段階
  • Commit

を中心とした履歴管理へ見直し、檢索性とトレーサビリティの向上を図った。

さらに、セッション終了時には計画書から完了濟み計画を削除し、履歴へ移すライフサイクルを採用した。


振り返り

今回のセッションでは、

  • AI隊
  • 投資アプリ
  • 五条ハーレム
  • 動画告知Bot

の複数プロジェクトへ小規模な改善を実施し、実装・檢証・コミット・ドキュメント更新まで一連のサイクルを回すことができた。

品質議論も、机上の議論ではなく実際のコードや運用へ反映する形へ変化してきた。

フェーズ1.5としては、品質設計を議論する段階から、通常開発を進めながら実運用で品質を評価・改善する段階へ移行できた、節目となるセッションだった。