👁️‍🗨️

四則演算の仕様をAIにマークダウンに分解してもろた

に公開
AI
アーキテクチャ
llm
Claude
Gemini API
tech

そんなことしてなんの意味が…？

いややってることはアレだけど（笑）どうやるかって話です

https://github.com/hiro51282/FlowNess/tree/main/poc/arithmetic

こちらのリポジトリで「こうしたらいいんじゃないの？」ってPoCを作ってます。

楽しい楽しい実験タイム。

このPoCでは、四則演算APIの要求（requirement.md）から、

  • add.md
  • sub.md
  • mul.md
  • div.md

の4つの仕様ファイルをAIさんが分解して生成するってやってみました、考えが甘いことは重々承知、要はコレをスケールすりゃあいいんですよ。

FlowNessの考え方に基づき、AIの生成をそのまま適用せず、
「工程」として制御する構造を検証しています。

今回のスコープ

今回のPoCでは、以下の範囲に限定しています。

  • requirement.md を入力として受け取る
  • LLM（Gemini）で仕様を分解する
  • JSONとして構造化されたデータを受け取る
  • Validationを通す
  • Approvalを通す（暫定ルール）
  • ファイルとして書き込む

各ノードの役割

DecompositionNode

  • AIが要求から仕様を分解してJSON形式で結果を返す

ValidationNode

  • チェックする！（今回はかなりゆるい）

今回は、Validationはフォーマットの成立限定しており、 ちゃんとしたチェックまでは行っていません。

ApprovalNode

  • OK/NGを判定する、現状は単純なルール

今回のPoCでは、Manager（人間による判断）は簡略化されてます。

ExecutorNode

  • 分解された仕様をファイルとして書き込む
  • LLMの出力内容には関与しない

実装のポイント

Stateベースのデータフロー

ノード間はstateのみで情報を受け渡します。

  • 各ノードはstateを受け取り
  • 処理を行い
  • stateを返す

という構造

LLM出力の扱い

raw = call_gemini(prompt)
specs = json.loads(raw)

LLMの出力は文字列として扱わず、
JSONとしてパースして構造化データとして扱います。

気になった点（PoCゆえの割り切り）

  • EXPECTED_KEYS のハードコード（四則演算専用）
  • Stateがdictベースで型がない（拡張時に壊れやすい）
  • Nodeのインターフェースが暗黙（runメソッドの契約がコード上に表現されていない）
  • Validation失敗時の戦略が弱い（Retry / Rollback未定義）
  • 設計はPoCレベル（抽象化・再利用性はこれから）

今後の課題：コード生成への拡張

自然言語混入問題

出力に説明文やコメントなどの自然言語がソースコードに混入するリスクがあります。ソースコード作ったはずなのに説明が入ってたりね。

コーディングエージェント使うとそれはそれで変なことになるからしっかりやらんとあかん。

現状の課題

  • Executorはcontentをそのまま書き込むだけ
  • コードと説明の区別がない
  • 実運用では不正なファイルが生成される可能性がある

必要な対応

  • コードブロックの抽出（```で囲まれた部分のみ取得）
  • 形式チェック（言語ごとの最低限の構文確認）
  • 差分生成（既存ファイルとの差分を明示）

方向性

  • Executor前に「コード抽出層」を追加する
  • LLM出力をそのまま信用しない
  • 「生成」と「適用」の間にもう一段の制御を入れる

まとめ

このPoCは「正しい仕様を生成すること」ではなく、

  • AIを工程として扱えるか
  • 制御された生成が成立するか

を検証するためのものです。

まずは小さく成立！

Discussion