ID:82804さん

https://github.com/horrible-gh/FlowGate # プロジェクト経験概要 AIエージェントの作業に「レビューゲート」を設ける個人開発プロダクト「FlowGate」（OSS／公開リポジトリ）。 自律型AIエージェントが「完了した」と主張する作業を、人間（または別エージェント）が承認するまで次工程に進ませない、型付きドキュメントパイプラインを設計・実装した。 形態：個人開発（GitHub公開・MITライセンス） ／ 企画・設計・実装・テスト・インフラまで一人で担当。 # プロジェクト概要・背景 - 【概要】FlowGateは、AIエージェントの成果を「主張」のまま通さず、承認ゲートを通過させてから次に進める仕組み。要件（Requirement）→タスク（Task）→タスクレポート（Task Report）と、各受け渡しがレビューゲートを通る構成。 - 【課題（なぜ作ったか）】自律型AIエージェントに開発タスクを任せると、「テストが通った」「バグを直した」「実装が完了した」と報告してくるが、実際には未完であることが頻発する。エージェントが「Xをやったと主張する」状態と「Xが受理された」状態の間に、構造的なゲートが存在しないことが根本問題だった。FlowGateはその“ゲート”を作るために開発した。 # 開発・実装内容 - 【どのような機能か】 - 型付きドキュメント＆自動採番：要件（R）・タスク（T）・タスクレポート（TR）・会話（CH）等を型として扱い、グループ単位で自動採番・連鎖させる。 - レビューゲート：承認／理由付き差し戻し／修正依頼を備え、却下履歴をドキュメントに保持。 - リモートワーカーAPI：エージェントがスコープ付きBearerトークンで認証しHTTP経由で成果を提出。トークンを消費せず検証する dry-run モードも実装。 - 構造化された質問（Q）：エージェントが不確実なとき、推測せずドキュメントに紐づく質問を登録し、確定回答へルーティング。 - ライブ更新：Server-Sent Events によるリアルタイム通知。 - 継続（無人）実行：継続トークンにより、エージェントがワークフローを自己連鎖で進め、目標ステージまで自動進行（レビュー時は人間Q&Aで一時停止可能）。 　── 思考プロセスの補足 ── 　【工夫】 　　・作業を「型付きドキュメントパイプライン」として再定義し、エージェントが“言うだけ”では完了にならず、認証付きAPIを通じて成果物を登録しなければならない構造にした。「主張」と「検証済みの状態」を分離することを設計の中心に据えた。 　　・バックエンドはPython / FastAPIでモジュール分割（api / auth / db / rbac / workflow / numbering）。SQLite / MySQL / PostgreSQLの3バックエンドに対応し、50本の順序付きマイグレーションと実行時のSQL方言変換層を実装。 　　・認証はJWT＋bcrypt＋TOTP二要素認証（バックアップコード付き）＋リフレッシュ／ブラックリスト、トークン単位のアクションスコープ、レート制限まで作り込んだ。 　　・Docker / docker-compose によるワンコマンド構築、systemdユニット、Linux／Windows両対応のセットアップスクリプトまでインフラ面も整備。 　【AIの活用】開発自体にClaude Code（コーディングエージェント）を活用。さらにFlowGate自身を自分の開発に使う「ドッグフーディング」を実施し、このREADMEを生み出した要件・作業指示自体もFlowGateを通して登録・レビュー・承認した。「何を作るべきか・どう設計するか」は自身が判断し、実装をAIで加速させる進め方を採った。 # 成果 - 【成果】企画から設計・実装・テスト・インフラ整備までを一人で完遂し、動作するシステムとして公開（プロトタイプではなく、自身の開発を駆動する実稼働パイプライン）。 - バックエンド・認証・ワークフローエンジン・マルチDB対応・リモートAPIを、テストを伴う中核として実装。 - テスト設計：各テストケースを「条件／期待結果／“起きてはならない”結果」まで定義し、正常系だけでなく異常系・想定外挙動も検証対象として設計。実装そのものはAIで生成しつつ、「何を検証すべきか」の判断は自身が担った。 - 設計・判断は自身が担い、実装をAIで加速させることで、個人開発でありながら実用レベルのシステムを構築した。 # 使用技術 - バックエンド：Python / FastAPI - フロントエンド：Vue 3 / Pinia / vue-i18n（ko・ja・en）/ vue-router / Vite / TypeScript - データベース：SQLite / MySQL / PostgreSQL（マイグレーション・方言変換層を自作） - 認証・セキュリティ：JWT / bcrypt / TOTP 2FA / レート制限（slowapi） - インフラ：Docker / docker-compose / systemd / SSE - 開発支援（AI活用）： - Claude Code（メイン）：設計をもとにした実装・リファクタリングの中心として活用。 - Codex：サブタスク・調査・テスト関連の補助として活用。 - GitHub Copilot：エディタ上でのインライン補完として活用。 - ※「何を作るべきか・何を検証すべきか」は自身が設計・判断し、実装をAIで加速させる方針で使い分けた。

https://horriblegames.net # プロジェクト経験概要（個人開発） Godot＋Python/FastAPIで自作した、マルチプレイ対応のカードゲームプラットフォーム「HorribleCards」（個人開発）。 ポーカー系5種（テキサスホールデム／セブンポーカー／バドゥギ／ハイロー／ミリオネア）を、シングル・マルチ両対応・マルチプラットフォーム（Windows / macOS / Android / iOS）・多言語（韓・英・日）で構築。AI対戦エンジン・リアルタイム対戦サーバを含め、企画から実装・配信まで一人で担当した。 期間：2026/02〜2026/05（約3ヶ月） ／ 形態：個人開発（1人企画・設計・PM＋AIワーカーによる実装加速）。 # 開発・実装内容A：AI対戦エンジンの設計（確率・期待値ベース） - 【概要】カードゲームのAI対戦を、学習ベースではなく確率・期待値（ルール）ベースで設計・実装。 - 【どのような機能か】 - MIMエンジン（MonteCarlo Inference Machine）：モンテカルロ・シミュレーション（既定200回）で自手の期待順位を推定し、順位ごとの期待値（EV）テーブルから raise / call / fold を決定。 - Phantomエンジン：EV計算・ベイジアンドロー・ドローMC計算・相手シミュレータ・パーセンタイルテーブル等の計算モジュール群。 - 相手モデリング：交換枚数×ベッティング強度から重みテーブル（プリセットJSON）を引き、仮想の相手ハンドを生成するBehavioral Prior方式。 　── 思考プロセスの補足 ── 　【課題】カードゲームAIをどう実装するか。当初は強化学習ベースのアプローチを検討し、自作の強化学習ライブラリ（ModularRL）をゲーム内のエンジンとして組み込むことを試みた。 　【工夫・判断】試作の結果、学習の安定性・サーバ運用コスト・意思決定の説明可能性の観点から、強化学習ベースはプロダクションに見合わないと判断。レガシーとして切り離し、本番エンジンはモンテカルロ＋EV＋ベイジアンのルールベースで再設計した。「動く高度なもの」より「安定して説明でき、運用コストが見合うもの」を優先した結果の選択。 　【成果】モンテカルロによる期待順位推定とEVテーブルに基づく意思決定エンジンを、純Python・依存なしで実装。挙動が説明可能で運用コストも抑えたAI対戦を実現した。 # 開発・実装内容B：リアルタイム対戦サーバの自作 - 【概要】FastAPI上にWebSocketによるマルチプレイ・ゲームサーバを自作。 - 【どのような機能か】 - 接続管理（websocket）＋ルーム管理（room_manager）＋メッセージルーティング（message_handler）を分離した構成。 - ゲームロジックはルーム・セッション・ラウンドの各ハンドラに加え、ゲーム別ハンドラ（バドゥギ／ホールデム／ハイロー／ミリオネア）、サイドポット対応のベッティングエンジン、AIコントローラを実装。 - リアルタイムな盤面状態はRedisで管理し、4種のゲームを単一サーバで処理。 　── 思考プロセスの補足 ── 　【工夫】接続・ルーム・メッセージ処理・ゲームロジックを明確にモジュール分割し、複数ゲームを一つのサーバ基盤で扱える構成にした。サイドポットなどポーカー特有の複雑な状態もベッティングエンジンとして切り出した。 　【成果】4種のカードゲームのリアルタイム・マルチプレイを、自作サーバ（FastAPI＋WebSocket＋Redis）で安定動作させた。 # 成果・規模 - ポーカー系5種を、シングル・マルチ両対応／4プラットフォーム配信／多言語（韓・英・日）で構築。 - 4つのサブプロジェクト（クライアント／サーバ／ルールエンジン／ホームページ）を一人で構成。ルールエンジンはカード評価器・MIM・Phantom・相手モデリング・専用テストスイートまで別モジュールとして分離した規模。 - 進め方：自身が企画・設計・PMを担い、複数のAIワーカー（Claude Sonnet / Haiku・GPT等）へ作業指示書を発注して実装を加速させる、1人マルチAI体制で開発した。 # 使用技術 - クライアント：Godot 4.6（GDScript）／ AdMob SDK連携 - サーバ：Python / FastAPI / uvicorn / WebSocket - データストア：Redis（セッション・ルーム状態）／ MySQL・PostgreSQL - 認証：JWT＋2FA - AIエンジン：純Python実装（モンテカルロ・EV・ベイジアン）※当初は自作強化学習ライブラリ（ModularRL）をレガシーとして試作後、不採用 - 開発支援（AI活用）：Claude（Sonnet / Haiku）・GPT 等を作業指示ベースで活用