AIが書くコードを理解するための道具が、AIと働く作業場「Mustard」になるまで
はじめに
Mustardは、AIコーディングエージェントと一緒に開発するためのデスクトップアプリだ。この5か月、自分が作り続けてきた。ターミナルでClaude CodeやCodexを動かしながら、Gitの履歴やGitHubのIssue・PRを横で見られ、役割の違う複数のエージェントにタスクを分担させることもできる。
ただ、最初からこれを作ろうとしていたわけではない。出発点は、AIと開発するようになって見えてきた、ひとつの課題だった。
出発点は「書く速さと、理解する速さの差」だった
コーディングエージェントを日常的に使うようになって、開発の詰まりどころが変わった。数百行の変更が数分で出てくる今、時間がかかるのは書くことではなく、その変更を理解し、レビューし、責任を持って出荷できる状態にすることだ。AIで開発するチームが増えるほど、「AIが書いたコードを、人がどれだけ速く正しく理解できるか」が品質とスピードを左右する。
そこで5月に作り始めたのが nunopi という学習ツールだ。コードや文章を貼ると、AIが一行ずつ処理の意図を解説し、用語や概念を整理してくれる。名前は韓国語の「눈높이（ヌンノピ）」から取った。「目の高さ」という意味で、相手の目線に合わせて分かりやすく伝えるときによく使われる言葉だ。
中でも力を入れたのが「質問」の扱いだ。作業中に分からないことが出てきて、Claude Codeの /btw のような脇道の質問を使ったり、そのままエージェントに聞いたりすると、メインの作業の会話に質問が混ざり、コンテキストが押し流されていく。かといって毎回Markdownに書き出して残すのも続かない。溜まったメモの分類を自分で決めるのは、もっと面倒だ。
nunopiの「質問モード」では、疑問ごとに独立した場所を用意した。ひとつの疑問の中で派生した質問を枝分かれさせ、芋づる式に掘り下げていける。やりとりは作業の会話と切り離されて残り、アーカイブされ、分類はエージェントが提案して自動で振り分ける。理解の邪魔をしていたのは知識不足よりも「残して整理する手間」のほうで、その手間を取り除くことをnunopi全体の設計方針にした。
グラフは、人ではなくエージェントに読ませる
7月の終わりには「リポジトリ分析モード」を作った。graphifyや「セカンドブレイン」の文脈で注目されていた、知識やコードをグラフとして構造化する「グラフエンジニアリング」の手法を、人がアーキテクチャを理解するための道具として使えないかと考えた。依存関係をグラフにし、コミュニティ検出でまとまりに名前をつけ、変更の影響範囲を色で示す。それなりに作り込んだ。
結果は、狙いと逆だった。ノードとエッジを人が一つひとつ追って構造を読み解くのは、それ自体が重い作業だ。理解のボトルネックを減らすはずの道具が、かえってボトルネックを大きくし、理解するという行為そのものを面倒なものにしていた。
グラフで構造化すること自体は正しい。問題は、読み手を人にしていたことだった。そこでコードの構造グラフはMCP経由でエージェントに渡し、リポジトリを素早く読んで問題の場所と直し方にたどり着くための地図として使わせることにした。人には、グラフを読んだエージェントが機能ごとの流れを整理して見せ、聞かれたことに答える。
学習ツールも、使われなければ意味がない
同じ頃、nunopiそのものも、このままでは使われなくなると感じていた。開発の最中に、わざわざ別のアプリを開いてコードを貼る。その一手間が残る限り、忙しいときほど開かなくなる。
ちょうどOrcaのようなADE（Agentic Development Environment）が出てきたタイミングだった。エージェントが書く量が増えた今、ボトルネックはエージェントがいま何をしていて、それがどういう意味なのかを理解することに移っている。だとすれば、学習ツールが目指すべきなのは、エージェンティックコーディングと同時に理解を助ける方向だ。バイブコーダーやジュニア開発者には学びの場になり、経験のある開発者にはレビューと判断を速くする道具になる。ここで、nunopiの中にADEとしてのワークスペースを作り始めた。
画面を行き来する開発を、やめたかった
もうひとつの動機は、画面の行き来だった。GhosttyのようなターミナルやOrcaのようなADEでエージェントを動かし、IssueやPRはブラウザでGitHubを開き、調査メモや計画のMarkdownはObsidianで開く。一つひとつは数秒の移動でも、一日に何十回も繰り返す。エージェントで開発しているエンジニアなら、誰もが抱えている不便だと思う。
自分にはADHDの特性があり、これが特に効いた。画面を切り替えるたびに集中が途切れ、ブラウザで別の通知に目が行き、戻ってくると何をしようとしていたのかを思い出すところから始まる。
開発に必要なものを、エージェントが動いている画面の周りに全部集めたい。8月5日、ターミナル、ファイルツリー、Gitのコミットグラフ、差分ビューを一画面に並べたワークスペースを作った。翌日にはターミナルを別プロセスに分け、アプリを閉じてもエージェントのセッションが生き残るようにした。
その後も、外に出ていく理由をひとつずつ潰していった。調査メモや計画のMarkdownをタブで並べて読めるドキュメントビューアを入れて、Obsidianに切り替えなくてよくした。IssueやPR、CIの結果を横で見られるパネルを足して、ブラウザに行かなくてよくした。動作確認用のブラウザもアプリの中に入れ、画面の要素を選んでそのままエージェントに伝えられるようにした。エージェントのツール呼び出しをイベントとして流し、いま何をしていて、それがどういう意味なのかをその場で解説する仕組みも入れた。変更を後から追いかけるのではなく、書かれていくそばから把握できる状態を作りたかった。
主役が入れ替わった日
ワークスペースを作ってから、自分の使い方もそのとおりに変わった。作業場が主役で、学習はその中で必要なときに呼び出すものになった。
9月17日、アプリの名前を Mustard に変えた。nunopiは、その中に載る学習モジュールという位置づけだ。軸がADEに移る以上、学習ツールの名前のままでは中身と合わない。日常で目にする言葉からいくつも候補を出し、「Must-have ADE（なくてはならないADE）」を縮めた「MustADE」、読みがそのまま「Mustard」に落ち着いた。
コミットと、それを書いた会話をつなぐ
チームメンバーから、アイデアをもらったこともある。「コミットごとに、どのClaudeのセッションのどこからどこまでで作られたのかが分かって後で問題が起きたとき、どういうやりとりでそのコードになったのかを振り返れる機能があったらいいな」と。
Gitに残るのは差分とコミットメッセージだけで、なぜその設計になったのかはエージェントとの会話の中にしかない。人が書いたコードなら本人に聞けばいいが、エージェントが書いたコードには聞く相手がいない。そこで、Claude CodeやCodexの会話ログから、プロンプトを送ったところからコミットした回答が終わるところまでを切り出し、要約と元の会話をカードにしてGitのグラフからたどれるようにした。レビューで「なんでこうなってるの？」と聞かれたとき、障害の原因を追うとき、当時の会話をそのまま開ける。AIと開発するチームにとって、これは単なる便利機能ではなく、自分たちのコードに説明責任を持つための記録だと考えている。
いま作っているもの：エージェントの「チーム」
役割の違うエージェントに仕事を分担させる「マルチエージェント・オーケストレーション」が話題になってから、もう数か月が経つ。マルチエージェントのフレームワークも数多く登場し、考え方自体はもう目新しくない。
ここ最近は、それを日常の道具にしたサービスが出てきた。9月末にOpenAIが発表したChatGPTの「Dots」は、任せてよい範囲を渡しておくと、会話が終わったあともクラウド上で作業を続ける常駐型のエージェントだ。Xで @grok とメンションして呼び出すGrok Botは、10月に入って、タスクに応じてClaudeなど他社のモデルも使い分けるモデルルーターになった。エージェントが常に動いていて、必要なときに呼ばれ、得意な相手に仕事を振る。そういう形が一般の人にも見える場所まで降りてきた。
これを開発の現場に持ち込むために作っているのが、Mustardの「Crew」だ。かんばんボードにカードを置くと、範囲を決める担当、実装担当、テスト担当、リリース前の確認担当といったエージェントが順番に引き継いでいく。大きなタスクはサブタスクに分けて依存関係の順に進め、やりとりはグループチャットのように流れる。チャットで @担当 とメンションすれば動き出し、CIの失敗や特定のラベルのIssueをきっかけにカードを自動で走らせることもできる。
DotsやGrok Botとの違いは、Crewがクラウドのサービスではなく、開発者が普段使っているコーディングエージェントのCLIそのものを、自分のマシンの、自分のリポジトリの上で動かすことだ。普段のサブスクリプションがそのまま使え、スキルやMCPの設定、プロジェクトのルールもそのまま効く。どのモデルを使うかはサービス側ではなく開発者が役割ごとに決めるので、Claudeが書いたコードをCodexがテストする、といった組み合わせを自分で設計できる。本物のCLIのセッションなので、途中で人がターミナルに引き取って続きから作業することもできる。
一番気をつけたのは、人間の出番をどこに置くかだ。既存のフレームワークでは、役割の割り振りがずれたり、エージェント同士の会話が終わらなくなったりするのがよく起きると言われている。だから順番や終わり方はコードで決め、差し戻しの往復には上限を置く。仕様を決めるとき、データを壊しうる変更をするとき、マージするとき。この3か所は必ず人が判断し、pushやマージは人がボタンを押したときだけ実行する。AIに任せる範囲を広げるほど、人が見るべき場所をはっきりさせておく必要がある。
おわりに
振り返ると、Mustardは計画どおりに育ったプロダクトではない。機能を捨て、名前を変え、主役を入れ替えてきた。そのたびに判断の材料になったのは、毎日使っている自分の感覚だった。
最近、nunopiを単体でも使えるアプリとして切り出した。学習ツールだけ使いたい人はnunopiを、エージェントと開発する作業場が欲しい人はMustardを、という形だ。これから少しずつ外に出していくので、その過程もまたこのブログに書きたい。
ご相談をお待ちしています
Neuradexは、AI・システム開発の受託に取り組んでいます。この記事で書いたように、私たち自身が毎日AIエージェントと一緒に開発し、その道具まで自分たちで作っています。AIを開発の現場や業務に組み込みたいとき、どこをAIに任せ、どこで人が判断するべきかを一緒に考えるところからお手伝いできます。
正直に言うと、受託の実績はまだほとんどありません。だからこそ、最初のお客さんとは一つひとつの案件に深く向き合いたいと思っています。
「AIエージェントを開発チームに入れてみたい」「社内の開発フローにAIを組み込みたい」といった段階のご相談も歓迎します。「こんなことできる？」くらいの軽いご相談でも構いません。気になった方は、ぜひお問い合わせからお気軽にお声がけください。