はじめに
AIに開発をどこまで任せられるのか。コードを1行ずつ書かせるのではなく、「AIが迷わず動ける土台」を先に整えておいたら、フロントエンド開発はどこまで効率化できるのか。個人的に気になって、IBM BobとMCP(Model Context Protocol)を使って検証してみた。
結論から言うと、土台さえ整えれば、コンポーネント作成やレビューのような定型作業はかなりの部分をAIに任せられる、という手応えがあった。
この記事は、その検証で「何を・どう仕組み化したか」の記録だ。ツールそのものより「考え方」と「実際に組んだ仕組み」に重きを置いて書く。良かったことだけでなく、つまずいた点も正直に残す。
本記事は筆者個人の検証と見解に基づくものであり、所属組織の公式見解を示すものではありません。
これはシリーズの第1回です。第2回では、ここで整えた.bobの設定をそのままClaude Codeへ持っていって検証した話を予定しています。
この記事で分かること
- AIが迷わないための「土台(ルール・モード・Skills・MCP)」の組み方
- Next.js / React / TypeScript構成でのAI活用ワークフロー
- 検証して分かった、効くコツとつまずきどころ
想定している読者
- AIコーディングを「補完」から一歩進めて、開発ワークフローそのものに組み込みたい人
- Next.js / React / TypeScriptあたりで開発している人
IBM Bobの細かい使い方そのものは他の記事に譲る。ここでは「考え方」と「実際に組んだ仕組み」を中心にする。
検証の狙いと前提
試したかったことはシンプルだ。「AIに毎回うまい指示を出す」のではなく、「AIが判断に迷わない前提を先に固める」と、開発がどう変わるか。
検証に使った構成は次の通り。新しめだが、AIとの相性を見たかったのもあって選んだ。
| 領域 | 採用したもの |
|---|---|
| フレームワーク | Next.js 15(App Router) |
| UI | React 19 + React Aria Components |
| 言語 | TypeScript 5 |
| 状態管理 | Zustand(UI状態) / TanStack Query(サーバー状態) |
| スタイリング | Tailwind CSS v4 |
| Lint/Format | Biome |
| テスト | Vitest / Storybook / Playwright |
| 設計 | Feature-Sliced Designをベースにした構成 |
題材は、よくある管理画面のような一覧・詳細・フォームを含むフロントエンド。特定の製品やサービスに依存しない、汎用的な画面構成を対象にした。選定理由は後述するADRに残してある。
考え方: 「書かせる」より「レールを敷く」
AIコーディングというと、つい「賢い指示を出して、いいコードを出してもらう」発想になりがちだ。最初は自分もそうだった。
でも、毎回うまいプロンプトを書くのは続かない。指示の質に成果物が左右されるし、人が変われば結果も変わる。再現性がない。
考え方を変えた。AIに毎回いい判断をさせるのではなく、判断しなくていいところまで前提を固める。 つまりレールを敷いておく。
レールにあたるのが、IBM Bobでいうところの次の4つだ。
順番に、実際に組んだ仕組みとして書いていく。
実際に組んだ仕組み
技術選定はAIを壁打ち相手にして、ADRに残す
技術選定は、自分の知見をベースにしつつ、AIを壁打ち相手に使った。
たとえば「Next.js 15のApp RouterとRemixを、今回の要件で比較してADRの草案を作って」と投げる。すると比較の観点と草案が返ってくる。それを自分で取捨選択して、最終的にADR(Architecture Decision Record)として残す。
ADRに残すのが地味に効いた。後から「なぜこれを選んだのか」を振り返れるし、AIにとっても、この文書自体が判断材料になる。
# ADR-001: Next.js 15 App Routerの採用
## 状況
フロントエンドフレームワークの選定が必要。
## 決定
Next.js 15(App Router)を採用する。
## 理由
- Server Componentsによるパフォーマンス上の利点
- App Routerが安定してきたこと
- React 19との相性
- エコシステムの厚み
## 影響
- Server/Client Componentsの使い分けが必要になる
- 一定の学習コストが発生する
選定の前にPOCも自分で回した。React Aria Componentsでアクセシビリティ対応がどれくらい現実的か、Biomeに寄せて運用できるか、VitestとStorybookの組み合わせはどうか。ここは「AIに任せる」より「自分で触って確かめる」フェーズだった。土台を作る側が確信を持てていないと、レールは敷けない。
規約は「暗黙の了解」を消す作業
コーディング規約づくりは、新しいルールを発明する作業ではなかった。頭の中にある「なんとなくこうしている」を、ぜんぶ言葉にする作業だった。
人間相手なら「空気を読んで」で通じることも、AIには通じない。逆に言えば、明文化さえすればAIは驚くほど忠実に守ってくれる。
優先順位もはっきりさせた。
- フレームワーク公式のガイドライン
- React / TypeScript / WCAG 2.1 AA
- プロジェクト固有の規約
- 慣習
そのうえで、コア原則は欲張らず数個に絞った(この「絞った」理由は後半のつまずき談で書く)。
なかでも一番効いたのが、機能(Feature)間の直接依存を禁止するルールだ。これは言葉で言っても守られないので、Biomeのルールで機械的にエラーにした。
- // 禁止: 別の機能の内部を直接importする
- import { SomeType } from '@feature-b/types' // @feature-a の中から
+ // OK: 共通化したものを使う
+ import { SomeType } from '@common/types'
{
"linter": {
"rules": {
"style": {
"noRestrictedImports": {
"level": "error",
"options": {
"paths": {
"@feature-a/*": "機能間の直接依存は禁止",
"@feature-b/*": "機能間の直接依存は禁止"
}
}
}
}
}
}
}
「規約はAIにではなく、まずLinterに守らせる」。これが地味に効く。AIも人も、最終的にはCIで止まるので逃げられない。
カスタムモード: AIに役割を1つだけ持たせる
最初、「なんでもできる開発モード」を1つ作った。これは失敗だった。何でもできると、かえって挙動が読めない。レビューを頼んだはずがコードを書き換え始める、みたいなことが起きる。
そこで、役割を1つに絞ったモードに分けた。
- コンポーネント開発担当: TypeScriptファイルしか編集できない
- レビュー担当: 読むだけ。編集権限を与えない
- 共通化アドバイザー: 「これは共通化すべきか」だけを判断する
ポイントは、権限そのものを絞ること。レビュー担当に編集権限を渡さなければ、レビュー中に勝手にコードが変わる事故は起きない。役割を言葉で頼むのではなく、できることを構造で縛る。
slug: code-review
name: Code Review
roleDefinition: |
コーディング規約のチェック担当。
機能間依存・アクセシビリティ・テストの有無を確認する。
groups:
- read
- command
- skill
# edit は与えない。だからレビュー中にコードは変わらない
Skills: いい作業手順を「1回きり」で終わらせない
うまくいった作業手順は、Skillとして固定した。毎回同じ流れで動いてくれるようになる。
コンポーネント開発では、Storybookを起点にしたTDDの手順をSkillにした。流れはこうだ。
人間が手順書を見ながらやることを、そのままAIの手順書にしたイメージだ。新しいコンポーネントを頼むと、この流れを毎回たどってくれる。だから出来上がりの粒度が揃う。命名もテストの観点も、人によってブレない。
実際に「Buttonコンポーネントを作って」と頼むと、こんな具合に進む。
実際の実行ログ(クリックで展開)
Bob: React Aria MCP: 接続成功
Bob: Storybook MCP: 接続成功
Bob: 仕様書を確認します
→ 配置先: @common/components/ui/
→ Props: variant, size, isDisabled
→ Stories: 4個 / Tests: 5観点
Bob: React Aria MCPでButton APIを確認
→ hover: / pressed: / focus-visible: / disabled: を使用
Bob: Storybookストーリーを作成 → button.stories.tsx
Bob: テストを作成 → button.test.tsx
→ pnpm test: 0/25 passed (まだ落ちる)
Bob: コンポーネントを実装 → button.tsx
→ pnpm test: 25/25 passed (通った)
Bob: Storybookで最終確認 → 完了
体感としては、1コンポーネントが手作業で30分はかかっていたものが、確認込みで数分で形になった。テストとStorybookが必ず付いてくるので、後工程のレビューもかなり軽くなる。
MCP: 「最新の正解」をAIに引かせる
AIは賢いが、知識は学習時点で止まっている。ライブラリのAPIは変わる。そこを埋めるのがMCPだった。
今回つないだのは主に4つ。
| MCP | 何を引くか |
|---|---|
| React Aria MCP | コンポーネントのAPIとアクセシビリティ要件。onPressなのかonClickなのか、使える状態バリアントは何か |
| Storybook MCP | ストーリーの書き方のテンプレート |
| Playwright MCP | ブラウザでの実機確認とE2E |
| Figma MCP | デザインから画面情報を取得 |
特にFigma MCPは、デザインからレイアウトや値を取り出して実装に落とす流れで効いた。デザイン情報を仕様書に落とし、必要ならトークンを整理してから実装に入る。この一連がスムーズに回ると、画面を組むスピードが目に見えて上がる。
検証して分かった手応え
土台が組み上がると、1画面相当を組むときの流れはだいたいこうなる。
派手なことは何もない。ただ、毎回同じレールの上を走るので、迷う時間がほとんど無い。「次に何をするんだっけ」が消えると、手はこんなに速く動くのか、というのが正直な感想だった。
正直、つまずいたところ
ここまで読むと万能に見えるかもしれないが、そんなことはない。検証中はつまずきのほうが多かった。隠さず書く。
利用枠(Budget)はすぐ減る。
Bobには利用枠があり、重い処理を回すと残量がみるみる減っていく。「とりあえず全部やって」のような大きい依頼を投げると、あっという間に枠を食う。結局、タスクを小さく刻んで必要なところだけ任せるのが、コスト面でも正解だった。
重い依頼は応答が返りにくいことがある。 大量のファイルを横断するような重いプロンプトだと、応答が返ってこず待たされる場面が何度かあった。対策は同じで、コンテキストを絞って小さく頼む。一度に全部やらせようとしないこと。
指示が曖昧だと期待した出力にならない。 難しめの設計判断や曖昧な指示では、想像していた成果物にならないことがあった。ここで効いたのが仕様書だ。前提を文書で先に渡しておくと、出力の精度がはっきり上がる。「いい指示を書く」より「前提を読ませる」ほうが安定する。
MCPが落ちると作業が止まる。 外部連携に頼りすぎると、つながらない日にまるごと止まる。だから仕様書を事前に用意して、MCPはあくまで補助という位置づけにした。
ルールは作り込みすぎると逆効果。 最初、規約を細かく書きすぎて、AIがかえって迷い始めた。コア原則を数個に絞り、細部は各モード側に持たせたら落ち着いた。「全部書く」より「効くものだけ書く」。
どれも、振り返れば「一度に欲張らない」という一点に収束する。土台づくりも、運用も。
副次的に良かったこと: 属人化が減る
レールが敷いてあると、経験が浅くても一定品質のものを作りやすい。モードを切り替えて手順に沿って頼めば、命名もテストも規約に沿ったものが出てくる。
「ベテランの暗黙知を、仕組みに変換して共有できる」。これはチームで使うことを考えたときの、いちばん大きな利点だと思う。AI活用の旨味は、速さよりむしろここにあるのかもしれない。
検証してみての結論
定量的に「何%削減」と胸を張れるほどきっちり計測したわけではない。ただ体感として、
- コンポーネント1つが、手作業で30分はかかっていたものが数分で形になる
- テストとStorybookが必ず付いてくるので、レビューが目に見えて軽くなる
- 画面1ページ相当も、迷いなく一気に組める
くらいの手応えはあった。
そして何より、速くなった理由は「自分の手が速くなったから」ではない。AIが迷わないレールを敷くことに時間を使ったから、というのが結論だ。役割が「コードを書く人」から「AIが働ける環境を作る人」に寄っていく感覚は、これからますます当たり前になっていく気がしている。
まとめ
- AIに「いいコードを書かせる」より、「迷わない土台(ルール・モード・Skills・MCP)を敷く」ほうに投資すると、開発は安定して速くなる
- 規約は明文化し、できればLinterに守らせる。役割は権限ごと構造で縛る
- うまくいった手順はSkillに固定して、1回きりにしない
- MCPで「最新の正解」を引きつつ、依存しすぎない保険(仕様書)も持つ
- 万能ではない。利用枠・重い処理・曖昧な指示でつまずく。小さく刻むのが結局いちばん速い
次回予告
第2回は、ここで整えた.bobの設定を、そのままClaude Codeの.claudeに持っていって検証した話を書く予定です。
先に結論だけ言うと、設定がほぼそのまま動いた。これは「ワークフローの設計が、特定のツールに縛られていなかった」ことの裏返しでもあります。そのあたりを次回じっくり書きます。
参考リンク
ここまで読んでいただきありがとうございました。AI活用のワークフロー設計の参考になればうれしいです。質問や「うちはこうしてる」があれば、ぜひコメントで教えてください。