この記事は VR法人HIKKY Advent Calendar 2025 の 5日目の記事です。
今日は株式会社HIKKYにてバックエンドチームに所属するsamyが担当します。
他にもたくさんの記事が投稿されます。
是非ご覧ください！
MUSUHIとは？
AgenticAI（20の専門エージェント）で仕様駆動開発を自動化するAIエージェントインストーラーです。
要件分析から設計、実装、テスト、展開までカバーし、フルスタックアプリやAI/ML/インフラまで拡張可能！
Claude Code、GitHub Copilot、Cursor、Windsurf IDE、およびAI CLI（Gemini、Codex、Qwen）をサポートしています。
もっと細かなことについては下記記事を是非ご参照ください。
私もMUSUHIを試すに辺り、参考にさせて頂きました。
この記事では、私が実際に試用した体験をもとに、新規プロジェクトをゼロから作った体験記を記載します。
ステップ1：環境準備
【前提】
Windows11 / WSL2
セットアップ
- 自分の作業ディレクトリを作成（プロジェクトを作りたいところ）
- 作業ディレクトリにmusuhiをインストール
npx musuhi
コマンドを実行すると、どのツールを使用するか選ぶことができます。
今回、OpenAIのAPIKeyを使用して進めていくため、Codex CLIを選択しました。
ここではご自身の使用しているAIサービスを選択してください。
セットアップ終わり！(早すぎ！！！)
ステップ2：プロンプトを投げて生成開始
セットアップが完了したら、チャットにプロンプトを投げます。
※チャットはVSCodeの拡張からCodexをインストールして使用しています。
このプロンプトについても、どのようなものを作りたいのかAIに要約してもらうと良いです。
以下は実際に使用したプロンプトで、日本語でも問題ありません。
@orchestrator 以下のフルスタックアプリを最初から最後まで全部作って！
・アプリ名：My Bookshelf
・機能：本の登録・一覧・編集・削除・検索
・認証：メール＋パスワードでユーザー登録/ログイン（JWT）
・フロント：React 19 + TailwindCSS + ダークモード対応
・バックエンド：Node.js + Express + SQLite
・追加機能：本の表紙画像アップロード（Cloudinary）
・ML：タイトルからジャンルを自動分類
・DevOps：Docker Compose + GitHub Actionsで自動デプロイ
・ドキュメント：READMEとAPIドキュメントも完璧に
全部自動で生成して、最後に起動方法教えて！
プロンプトを投げると、初回は「書き込み権限が無いよ！」という旨の回答がありますが、書き込みして良いよと返せばOKです。
I can build the full “My Bookshelf” stack end-to-end, but the environment is currently read-only. Please approve running commands with write access so I can scaffold and modify files.
書き込み許可する！！
最初のプロンプトでメンションしている orchestrator ですが、MUSUHIは最初に記載の通りに20の専用エージェントが存在します。
その中でも、orchestratorは仕様駆動開発の中のステップを一気に処理してくれる頼れるやつです。
今回、プロジェクトを作成するために指示したのはこれだけです！
書き込み許可は必要でしたが、ほぼ1プロンプト
実際にファイルの出力が開始されると、これで良き？と確認してくれます。
本来は中のコードを確認した上でRejectすることもあるかもしれません。
今回は全部Allow this sessionを押します。
ステップ3：生成されたプロジェクト構成
大体10分～20分くらい（ボタンポチを待ち含む）でプロジェクトが仕上がります。
実際に出来たMy Bookshelfの構成は以下となります。
.
├── .codex
├── .github
├── .gitignore
├── README.md
├── backend
│ ├── .env
│ ├── .env.example
│ ├── .eslintrc.json
│ ├── Dockerfile
│ ├── data.sqlite
│ ├── package-lock.json
│ ├── package.json
│ ├── src
│ │ ├── config.ts
│ │ ├── db.ts
│ │ ├── index.ts
│ │ ├── middleware
│ │ │ └── auth.ts
│ │ ├── routes
│ │ │ ├── auth.ts
│ │ │ └── books.ts
│ │ ├── services
│ │ │ ├── classifier.ts
│ │ │ └── cloudinary.ts
│ │ └── types.ts
│ └── tsconfig.json
├── codex-config.md
├── docker-compose.yml
├── docs
│ ├── api.md
│ └── requirements
│ ├── functional
│ ├── non-functional
│ ├── requirements.ja.md
│ ├── requirements.md
│ ├── srs
│ └── user-stories
├── frontend
│ ├── .eslintrc.json
│ ├── Dockerfile
│ ├── index.html
│ ├── package-lock.json
│ ├── package.json
│ ├── postcss.config.js
│ ├── src
│ │ ├── App.tsx
│ │ ├── api.ts
│ │ ├── components
│ │ │ ├── AuthForm.tsx
│ │ │ ├── BookForm.tsx
│ │ │ ├── BookList.tsx
│ │ │ └── Header.tsx
│ │ ├── hooks
│ │ │ └── useDarkMode.ts
│ │ ├── index.css
│ │ ├── main.tsx
│ │ └── types.ts
│ ├── tailwind.config.js
│ ├── tsconfig.json
│ ├── tsconfig.node.json
│ └── vite.config.ts
├── package-lock.json
├── package.json
└── steering
├── product.md
├── rules
│ ├── agent-validation-checklist.md
│ ├── ears-format.ja.md
│ ├── ears-format.md
│ └── workflow.md
├── structure.md
├── tech.md
└── templates
├── design.ja.md
├── design.md
├── requirements.ja.md
├── requirements.md
├── research.md
├── tasks.ja.md
└── tasks.md
ステップ4：起動と動作確認
出力物にはREADME.mdも含まれています。
その内容通りに実施しますが、もし問題が出た場合はAIに確認を取りつつで大丈夫です。
下記は実際のREADME.mdの抜粋です。
実際の起動したアプリは以下のようになりました。
ログイン画面
アカウント新規作成画面
本を登録する画面
登録した本の一覧画面
ステップ5：修正・拡張
出来上がったプロジェクトを動かしてみて、バグや意図通りに実装されていない部分は修正してもらうことができます。
実は、作り立ての時にこのプロジェクトはCompletedボタンを押してないのに絶対Completedになるバグを抱えていました。
そのバグを直してもらいます。
今回はコード修正になるので、メンション先をsoftware-developerに変更します。
ただ、ここで指示文が甘いと泥沼の修正地獄に陥ります。
最初に「completedを選択していないにcompleted状態になるので直して」とだけ投げました。
最初boolean型だったのがnumberになりよくわからないmapが増えて、よくわからないstatusが増えて、is_completedの名前に反する修正がどんどん入って、バグも直りません。
めちゃくちゃになっていくコードを一発で直したのが以下の指示でした。
@software-developer
is_completed の部分の処理がややこしい気がするのでリファクタリングしてください。
codexの返答
is_completed の扱いをシンプルにしました。DBは数値(0/1)で保持し、APIレスポンスは boolean に変換するだけの軽い処理に整理しています。
変更内容
backend/src/types.ts: Book の is_completed を boolean に変更。DB行用の BookRow（数値）を追加。
backend/src/routes/books.ts:
toBook で BookRow → Book を一箇所で変換。
一覧/作成/更新のレスポンスは toBook 経由で boolean を返すだけに簡素化（複雑な map ロジックを排除）。
DBとのやり取りは数値のまま、返却時のみ boolean 化。
やること
バックエンドを再起動して動作確認してください。既存データは 0/1 のままでもレスポンス時に boolean に変換されます。
恐らく、保存時にbooleanからDBへ保存の値に変換をかけるときに何かしらのバグが入り込んでいたことが原因のようなので、指示文を出すときはコードを一読することをお勧めします。
さて、拡張も修正と同じようにsoftware-developerにお任せできます。
仕様書などを作成していた場合は別途他のエージェントに依頼すると思いますが、今回はコードの修正だけさくっと行います。
@software-developer
your booksの一覧画面をリスト形式に変更
表示する情報は現状のまま
ページャを5件の単位でつけて
現在一覧の表示はブロックになっていて、人がこの仕様変更を受け取った場合、心穏やかではないことでしょう。
即時反映してくれました。
追加でもっとお願いしちゃいます。
不採用したブロックを復活させようとします。
@software-developer
your booksの表示について、
最初のブロック表示と今のリスト表示をタブで切り替えるようにできる？
codexの回答
Your Books にビュー切り替えタブを追加し、グリッド表示とリスト表示をトグルできるようにしました。ページャ（5件単位）とフィルタは両ビュー共通です。
変更箇所:
frontend/src/components/BookList.tsx: view state（grid/list）を追加し、ヘッダーに切替ボタンを配置。グリッド（従来カード）とリスト（分割リスト＋編集）を条件描画。ページングと検索は共通の paged データを使用。
反映にはフロントの再ビルド/再起動後にリロードしてください。
文句ひとつなくタブの追加実装が行われました。
まとめ
MUSUHIを使用してプロジェクトの新規作成、簡単な改修までをざーっと通しました。
MUSUHI自体は動作させる環境を構築する、という作業がほとんどなく、即始めることができました。
また、作りたいものが決まっていれば、Orchestratorが必要なファイルの作成、実装、テストまで実施してくれます。
前章で書きました通り、仕様変更やリファクタリングも多少指示の工夫は必要になる部分もありますが、即座に対応することが出来ました。
既存プロジェクトや大きなプロジェクトに対応させるには、AI側の調整が追加で必要になるようですが、個人で作る小規模プロジェクトや、モック作成などにはピッタリかと思います。
個人的に使用してみて、「仕様これでよろしく！」でプロジェクトが作りあがっていくことに驚きと、そして上手に使うことにより作業時間の短縮などを期待することが出来ました。
しかし課題としてはやはり人間側で、「正確に伝えるにはどのような指示をするか」ということは考えていく必要があります。
それでも、AIを使って自動的にプロジェクトを作っていくということに、とても希望を持つことが出来ました。
この記事をきっかけに、自分でも何か作ってみようかな！と思うことがあれば幸いです。