田中のAI実装アプリは、なぜ「個人の便利ツール」で終わらず、会社全体の案件に効いているのか

vibeコーディングという言葉が広まりだしたときから、いわば「継ぎ足しの秘伝のタレ」のようにルールやスキルを蓄積することは開発効率化の重要な鍵となっている。そのとき、個人で抱えるよりもチームで蓄積したほうが当然効率はよく、チーム全体の生産性の向上につながる。しかし、実際にそれを社内標準のソフトにまで落とし込み、さらに使う側の判断で改善が返ってくる構造まで作っている会社はそう多くないのではないだろうか。

TamaTでは、エンジニアの田中が自作したAI実装アプリ「izanagi」を、社内の標準装備として運用している。今回はその作り手である田中と、現場で使い倒している増田とで、個人の工夫がどうやって会社全体の案件に効く形へ変わっていったのか対談を行った。

「izanagi」 とは、AIエージェントを使った実装ワークフローを社内向けにまとめたデスクトップアプリだ。worktree の作成、エージェントの起動、ブラウザでの動作確認、PR までの導線をひとつの画面に寄せている。それにより、要件をドキュメント化してさえいれば、ボタン操作のみで、

1. 実装方針の作成
2. 方針のレビューとブラッシュアップ
3. 実装
4. UI表示
5. PR作成

までを、全て自動で行ってくれる。

既存ツールでは足りなかった

増田： 最初から izanagi を作るつもりだった、って感じではなかったですよね。何が一番の詰まりどころだったんですか。

田中： 最初は ghosty + zellij + agent cli の構成でやってた。claude と codex を組み合わせたレビューワークフローを自分で組んでて、それ自体は回ってた。ただ、エディタ要員で yazi を入れたり、細かい工夫を積み重ねないと回らない。

増田： 細かい不便が、ずっと残る感じだったんですね。

田中： そう。モデルのアップデートで得意不得意が短期間で入れ替わるから、レビュー側に置いてたモデルを実装側に回したい、みたいなシーンも増えてくる。役割を入れ替えたいのに、agent のスキルにベタ書きで依存してると動かしにくい。あと、最初のプロンプトって結局定型文なんだよね。それを毎回手で打ってる時間ももったいない。ボタン操作だけでワークフローを動かしたかったし、codex がスクロールできなかったり、細かいバグでつっかかるのも地味に集中力を削る。細々したタスクをその都度こなすより、一括で解決したほうが長期的にはコスパがいい、って判断だった。

「地味な楽」を積み上げる

増田： 実際、作ってからたけさん (田中) 自身の案件では何が一番変わりました？

田中： 開発スピードは段違いに早くなった。エラーで止まるまではエージェントが自律的に動く。worktree の自動作成までボタン一回で勝手にやってくれる。ブラウザ統合があるから動作確認もそのままできるし、PR を作ったらそのリンクを直接踏める。

田中： 派手な機能というより、地味な楽を積み上げていく、って感覚に近い。結果として、月の PR 数は 2〜3 倍になった。並列で走らせられるようになったのが大きい。

増田： ghosty + zellij でやってたことと、できること自体は一緒なんですよね。なので、新しいツールと言っても質は担保されてるなという感じがあって、導入の心理的なハードルは低かったです。CLIの構成だと git worktree の切り替えが若干煩雑だったんですけど、それが UI でできるとか、そういうメリットはかなり大きかったです。

増田： 地味な作業でつっかかると、そこで集中力が切れたりして、効率悪いんですよね。それを消してくれる。

なぜ「田中一人の道具」で終わらなかったか

増田： でもこれ、たけさん一人の道具で終わってもおかしくなかったと思うんですよね。なんでチーム全体に広がったんですかね。

田中： zellij でやってた時代から、レイアウトファイルは個人リポジトリで公開してた。チームで使ってもらうための前提はそこからあった気がする。

田中： ただ、スキルベース、つまりプロンプト単位で配布する形だと、結局プロンプトを書く人間の能力が問われちゃう。会社全体の生産性を上げようと思うと、初動のプロンプトの質も担保しなきゃいけない。

田中： そこで、レビューとの組み合わせで、誰がダウンロードしても基本的には同じ品質のものが作られる、って構造にした。issue を作るところ以外は、ボタンを押すだけ。プロンプトを書くことすらしない。手を入れるとしても軽微なバグくらい。

田中： docs と issue が作れるところまでできれば、あとは押下と QA だけ。新入社員でも動かせる。

増田： 使う側からすると、そこが大きいんですよね。ghosty + zellij で担保していたやり方自体はそのままで、品質を崩さずに UI で再現しやすくなった。案件ごとに worktree を切り替えたり、確認の動線を揃えたりできるので、同じやり方を別案件にも持ち込みやすいです。

田中： 質は落とさずに、並列でやれるようになった感覚はあるね。

知見は逆方向にも流れる

増田： 逆に、こっちから返した要望も結構ありましたよね。

田中： 10項目くらいレビューをもらった。中でもオプション切り替え、ショートカットキーの割り当ては効果的だった。

増田： たけさんに「ターミナルがデフォで出てくれると嬉しい」っていうのも投げましたね。dev サーバの立ち上げを worktree ごとにやりたいシーンが多いので。

増田： そういうやりとりは Slack で気軽に投げられるんですよね。出社してるから口頭でも伝えられるし、お互いのローカルの開発環境を直接目視で確認できるので、スクショを撮って送る、みたいな手間もないです。

田中： そう。作った側が一方的に配布するんじゃなくて、使う側からの要望をすぐ取り入れられた方がアプリの質は上がっていくね。

チームでAIを回す難しさ

増田： きれいな話だけじゃなくて、難しいのはやっぱり上流ですよね。

田中： さっきも言ったけど、スキルベースだとプロンプトの能力が問われる。会社としての生産性を上げようとすると、初動のプロンプトの質を担保する必要がある。上流さえ固められれば、あとは均一化できるんだけど、その上流が一番難しい。スキルも知見も求められる。

田中： スキルがあったとしても、一回 docs を清書したあと、レビューを別モデルで回して精度を高めるから、時間もかかる。

増田： あとはモデルの移り変わりに追随しないといけないですね。ハーネスとモデルの組み合わせでも挙動が変わるので。

田中： うん。一度作って終わり、にはならない。

TamaTらしさはどこにあるか

田中： 自分たちで IDE が組まれていて、そのリソースがシェアされている、っていうのは強いんじゃないかな。モデルを出している会社にいかに乗っかるか、っていう設計。モデルが進化すれば社内の izanagi も進化する。

増田： AI ツールを社員にただ提供するだけじゃなくて、社内で組んだ使い方やインフラまで含めてシェアされているっていうのは一歩進んでいる感じがあります。個々人が持つツールの新しい知見の発見を、個人で抱えずに集約できる。抱えてても効率悪いんですよね、これだけ変化が速いと。

これから強くしたいこと

田中： 社員の学習の部分だね。AI 活用すれば誰でも開発できる分、技術への理解度は浅くなるっていうジレンマを、教育ツールとして解消したい。

増田： 各モデルの新機能を自動で拾ってくる wiki みたいなものがあってもいいかもですね。

田中： あとはデザインツールと仕様書の統合。今はissueと仕様書は実装に向けて紐づけられているけど、issue・仕様書・デザインツールの三者全てを、双方向で結びつけたい。

増田： 確かに仕様書からデザインできるところまで持っていけば最強ですよね。Figmaも結局クライアントとの接点では使い続けるでしょうし。

田中： うん。アプリ単体の話じゃなくて、開発の流れ全体をどう設計し直すか、っていうフェーズに入ってると思う。

最後に

AIで楽をしたい人には、この話は少し地味に見えるかもしれない。TamaTが共有しているのは、派手なデモではなく、issueを切り、docsを起こし、reviewを通すまでの判断の型そのものだ。個人の工夫がチームに渡り、別案件で検証され、また道具に戻ってくる。そういう循環に面白さを感じる人は、ぜひ力を貸してほしい。