Fuya Makino

AI Agent Systems / Web Engineer

曖昧な課題を、運用できるソフトウェアに変える。

AIで速く作るだけではなく、何を任せ、どう検証し、どこまで権限を渡し、どう直し続けるかを設計します。

つくる速さではなく、運用の境界を設計する。

AI支援開発の基盤、ユーザー向けプロダクト、実運用したAIオーケストレータ。異なる対象でも、曖昧さを分解し、検証可能な仕事へ変える考え方は同じです。

01

agent development system

個人開発 / 設計・実装・検証

ai-repo-ops

AI支援開発の運用基盤を複数repoへ配布し、AI変更とrepo-owned stateをAIなしで決定的検証するCLI。

Problem

AI支援開発を複数repoへ展開すると、管理された設定とrepo固有の状態が混ざりやすい。AIが変更した結果を、AI自身の説明に頼らず人間が判定できる境界も必要になる。

Design

managedとlocalを分離し、.ai/ai-repo-ops.lock.yamlに同期状態を持たせる。初回生成したCI callerから中央のreusable workflowを呼び、repoごとの差分を同じ境界で扱う。

  • aro guardをrequired checkとし、.ai/project.yamlの変更自体をguard violationとして意図的にfailさせ、人間の明示overrideを要求する。

Operation

導入PRではguardを検証不能としてskipする。通常の変更はrequired checkと明示overrideを人間が確認してから運用へ渡す。

02

user-facing product

個人開発 / 設計・実装・検証

warikapp

同棲カップル向け。レシート写真をAIで品目分解し、自分・相手・折半に仕分け、差額計算・精算までつなぐ。

Problem

二人でまとめて払ったレシートは、品目ごとに「自分・相手・折半」を決め、最後に差額を計算する手作業が残る。金額だけを割ると、実際に誰が何を買ったかが反映されない。

Design

自作のReceiptParserインターフェースでOCR providerを画面とドメイン処理から分離し、AIの候補を品目ごとの編集可能な負担表へ変換する。利用者が確認・修正してから確定できる状態を画面上に残した。

Stack: Next.js 16 / React 19 / Convex / Clerk / Vercel

warikappでレシートの品目を自分・相手・折半に仕分けるプロダクトプレビュー
レシートの品目を確認し、負担者を仕分ける画面。

Operation

RECEIPT_AI_PROVIDERでOCR providerを切り替え可能にし、convex-test + edge-runtimeでnpm testを実行する。AI出力は利用者が確認してから確定する。

03

multi-agent orchestration, retrospective

個人開発 / 設計・実装・運用・振り返り

Kumichou Orchestrator / dark-part-time-job

複数のAIエージェントへ役割と作業環境を割り当て、タスク分解・並列実装・レビュー・再作業をつなぐオーケストレータ。

Problem

一つの長いAIセッションに全体方針、実装中の試行錯誤、レビュー、再作業を載せると、監督者と作業者に必要なコンテキストが混線する。人間がworkerごとの配膳係になる問題も残っていた。

Design

親分・若頭・workerを別sessionに分け、タスクをYAML queue、結果をreportとして受け渡す。sessionごとにgit worktreeを分離し、各paneを同じ作業環境へ切り替える。yb CLIから任意のリポジトリへオーケストレーション層を導入できる形にした。

Stack: tmux / YAML queue and reports / git worktree / configurable agent CLIs

Operation

実際の開発へ投入して改善を重ねた結果、ボトルネックは実装からqueue・report・review/rework・統合の管理へ移った。モデルと標準ツールの能力向上も踏まえ、日常利用から引退させた。作ったものだけでなく、使わなくなった理由と現在の判断まで公開している。

AIとの分担を、運用の設計にする。

AIの自己申告ではなく、成果物・テスト・Git状態で完了を判断する。人間が持つべき決定を残し、失敗を次の規則へ変えます。

  1. 01

    Define

    曖昧な課題を、目的・制約・完了条件が確認できる要件へ変える。

  2. 02

    Build

    仕様と責務を分け、AIへ任せる作業と人間が握る判断を決めて実装する。

  3. 03

    Verify

    成果物・テスト・Git状態を突き合わせ、AIの自己申告だけで完了にしない。

  4. 04

    Publish

    採否・権限拡大・mergeを人間へ残し、判断と失敗を次に使える運用規則として公開する。

採用するか、権限を広げるか、mergeするか。便利さのために自動化できることと、責任を持って人間が決めることを分離します。

  • 失敗は隠さず、次の入力・検証・権限ルールへ変える。
  • 運用に渡す条件は、成果物と再現可能な検証で説明できること。

Workflow skills

要件から発信までをつなぐ6つの skill

requirements-definitionfigma-make-specimplement-from-spec verification-checklistshared-agent-skillszenn-x-publisher

周辺の道具も、判断の履歴として公開する。

小さな道具にも、使う人・境界・やめる判断があります。実際の説明とソースをそのまま辿れるようにしています。

  • mdlog-mcp

    MCP server

    日付つきMarkdownログを全文検索。日次テックダイジェストの検索に常用しています。

  • claude-tts-hook

    Claude Code hook

    VOICEVOXによる自動読み上げ。チャンク分割・先読み合成・割り込みまで設計しました。

  • md-qr-serve

    VS Code extension

    MarkdownをローカルHTTPで配信し、QRコードから別端末ですぐ読めるようにする拡張。

判断を、結果だけで終わらせない。

成功談だけでなく、採用しなかった案や、使うのをやめた理由も書いています。

Claude Codeと作ったAIオーケストレータを、私はなぜ使わなくなったのか

作った事実より、運用して分かった限界と次の判断を残した振り返り。

記事を読む

Claude Code×ずんだもん読み上げはN番煎じだったので、「実用に耐える設計」の話をする

読み上げの待ち時間、先読み、割り込みをどう扱ったか。

記事を読む

Contact / 05

AI開発の運用や個人開発の話なら、たぶん盛り上がれます。

技術の話、設計判断の交換、仕事につながる相談を歓迎しています。Xから気軽に声をかけてください。