本日、フィールフロウのサイトに「Powered by FeelFlow AI」というバッジが加わりました。FeelFlow AI プロダクト（SaaS）をはじめ、私たちの全サービスを駆動する技術基盤を「FeelFlow AI」という名前で呼ぶことにしたのです。
こういう発表をすると、よくいただく反応があります。「AIで開発しているんですね。品質は大丈夫なんですか？」
正直な答えはこうです。AIで開発しているから品質が保てるのではありません。AI開発を組織として統制する仕組みがあるから、品質が保てるのです。
この記事では、その仕組み — 社内で「FeelFlow AI Plugins」と呼んでいるプラグイン・ガードレール群 — を、実際の設定ファイルを見せながら紹介します。開発裏話として、普段は表に出ない部分です。
FeelFlow AI Plugins とは
FeelFlow AI Plugins は、フィールフロウの開発で使う AI コーディングエージェント（Claude Code と Codex）に組み込んでいる、プラグイン・フック・品質ゲート群の総称です。単一のツールではなく、役割の異なる 4 つの層で構成されています。
- ガードレール層 — AI の危険な操作を機構で止める
- 品質ゲート層 — AI が書いたコードも人が書いたコードも同じ関門を通す
- 知見の資産化層 — 失敗から得た学びをコードとルールに変換する
- 公開版 — 汎用化できた部分を ff-dev-toolkit として OSS 公開する
重要なのは、これらが「一度作って終わり」ではないことです。AI エージェントの挙動は日々変わり、新しい失敗パターンも日々見つかります。FeelFlow AI Plugins は毎週のように更新される、生きた基盤です。
第1層: ガードレール — AI に「お願い」しない
AI エージェントに「develop ブランチを直接編集しないでね」とプロンプトで頼むことはできます。しかし、指示は忘れられることがあります。私たちは、頼む代わりに機構で止める方針を採っています。
実際のフック設定の一部がこれです（Codex 側プラグインの hooks.json から抜粋。Claude Code 側は .claude/settings.json に、matcher 名をエージェントのツール体系へ合わせた同等の配線があります）。
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash|exec_command|shell",
"hooks": [{ "type": "command", "command": "hooks/pre-pr-review.sh" }]
},
{
"matcher": "Edit|Write|apply_patch",
"hooks": [{ "type": "command", "command": "hooks/pre-branch-guard.sh" }]
}
]
}
}pre-branch-guard.sh は、AI がファイルを編集しようとした瞬間に現在のブランチを確認し、develop や main の上なら編集そのものを拒否します。pre-pr-review.sh は、セルフレビューを通っていない PR の作成をブロックします。
ポイントは、この同じガードレールを Claude Code と Codex の両方に敷いていることです。Claude Code には .claude/ 配下のフックとして、Codex にはプロジェクトローカルなプラグインとして、同じシェルスクリプトを配線しています。どの AI エージェントを使っても、守られるルールは同じ。エージェントを乗り換えても統制は壊れません。
第2層: 品質ゲート — AI のコードだけを特別扱いしない
「AI が書いたコードはレビューを厚めに」という運用をよく聞きます。私たちの考えは少し違って、誰が（何が）書いたかに関係なく、同じゲートを通らなければ push できない構造にしています。
リポジトリの pre-push フックは、push のたびにこの順でチェックを走らせます。
pre-push-guard.sh # ブランチ保護の最終確認
pnpm test:unit # ユニットテスト
pnpm format:check # フォーマット検査
pnpm lint:md # ドキュメントの lint
pnpm check # Astro + TypeScript 型検査
pnpm build:e2e # 本番相当ビルド
pnpm test:e2e # Playwright E2E テスト順序にも意図があります。数秒で終わるユニットテストを先頭に、数分かかる E2E を最後に置く cheap-fail の並びです。失敗するなら早く失敗させて、AI にも人にも修正のフィードバックを最短で返します。
このゲートがあるので、AI エージェントに大きめのタスクを任せても、「気づいたら型エラーのままマージされていた」という事故は構造的に起きません。実際、今日の FeelFlow AI リブランドの作業でも、フォーマット差分やモバイル表示のテスト失敗をゲートが push 前に捕まえています。
第3層: 知見の資産化 — 失敗を Playbook とコードに変換する
ガードレールと品質ゲートは「今日の事故」を防ぎます。しかし本当に効いてくるのは、失敗から得た知見を翌日の構造に変換するループです。
私たちは ACE（Agentic Context Engineering）と呼ぶサイクルを運用しています。PR がマージされるたびに、Generate（知見の抽出）→ Reflect（評価・重複確認）→ Curate（Playbook への蓄積）の 3 フェーズを回し、学びを構造化された Playbook エントリとして記録します。エントリは現在 450 件に達し、AI エージェントは実装時にこの Playbook を参照します。
さらに一歩進めて、知見はドキュメントに留めずコードそのものに埋め込みます。たとえばコンテンツのスキーマ定義には、こんなコメントが入っています（実物からの抜粋です）。
// 一覧カード / OGP meta description / RSS `<description>` に流れる
// consumer 境界フィールド。（中略）blog と揃えて 300 文字上限でビルド時に弾く
// (ACE-052: 必須文字列は .min(1)、consumer 境界は .max(N))。
excerpt: z.string().min(1).max(300),ACE-052 は Playbook のエントリ番号です。過去の失敗から生まれたルールが、スキーマのバリデーションという「破ると通らない」形に変換され、その根拠がエントリ ID で辿れる。知見が単なる社内メモではなく、ガードレールの設計図として機能している状態です。
第4層: 公開版 — ff-dev-toolkit
FeelFlow AI Plugins のうち、フィールフロウ固有の事情を取り除いて汎用化できた部分は、ff-dev-toolkit として Apache License 2.0 で公開しています。Issue 起票から PR レビュー、マージ後のクリーンアップと知見キャプチャまでのワークフローコマンド群を、Claude Code と Codex の両方から使える形で提供するものです。
エージェント拡張の共通規格については、Agent Plugins 1.0 を読み解いた記事でも書きました。社内基盤（FeelFlow AI Plugins）で実戦検証し、汎用化できたものを公開版（ff-dev-toolkit）へ流す — この二層構造が、私たちの OSS との付き合い方です。
なぜここまでやるのか
フィールフロウには AI First という行動指針があります。「AI を使わない選択には、明確な理由が必要」という考え方です。しかし AI First を本気で実践するほど、AI の失敗と向き合う回数も増えます。ハルシネーション、意図しないファイル操作、指示の取りこぼし — どれも実際に経験してきました。
その経験から得た結論は、「AI を信頼するかどうか」を議論するより、信頼しなくても事故が起きない構造を作るほうが速い、ということでした。私たちはこの領域を AIハーネスエンジニアリングと呼び、ガードレール設計と root cause 分析の手法として体系化しています。FeelFlow AI Plugins は、その社内実装にほかなりません。
FeelFlow AI プロダクトの品質は、モデルの賢さだけに依存していません。賢いモデルと、それを統制する組織の仕組み。この両輪が「Powered by FeelFlow AI」というバッジの中身です。
おわりに
同じ仕組みを自社の開発チームに入れたい、という方に向けて、システム開発 AI伴走コンサルティングではガードレール設計を含む AI 開発プロセスの定着を支援しています。まずは自社の開発フローのどこに「お願いベースの統制」が残っているかを棚卸しするところからでも、お気軽にご相談ください。