エージェント駆動開発の現在地
「コードを書く」という行為が、もはやエンジニアの主たる業務ではなくなりつつある。Opus 4.5の登場以降、我々シニアエンジニアの役割は、キーボードを叩いてロジックを構築することから、AIエージェントという名の「優秀だが文脈を読み違える部下」をいかに制御し、正しい方向へ導くかという「ループエンジニアリング」の設計へとシフトした。しかし、Web開発でこのパラダイムが急速に浸透する一方で、モバイルアプリ開発の現場には依然として「実機検証」という名の巨大な壁が立ちはだかっている。SimulatorやEmulatorの起動、ビルドの待ち時間、そして何よりUIのインタラクション確認という、自動化が極めて困難な領域だ。
テラーノベル社のkazutoyo氏が実践する手法は、この「モバイル開発のボトルネック」を正面から突破しようとする試みである。彼らが採用しているのは、AIエージェントが直接iOS SimulatorやAndroid Emulatorを操作する『agent-device』を用いたワークフローだ。これは単に「AIにコードを書かせる」というレベルを超え、計画から実装、検証、そしてPull Requestの作成までを一つのループとして完結させる、極めて実践的なエンジニアリングである。ここで重要なのは、AIに丸投げすることではなく、AIが「正しく動ける環境」を人間側が徹底的に整備するという、逆説的なアプローチである。
具体的には、実装前の「計画」段階で『superpowers』や『grill-me』といったスキルを活用し、仕様を言語化・明確化する。ここで仕様が曖昧であれば、後続の工程はすべて崩壊する。これは、要件定義が不十分なままコーディングを開始し、結果としてスパゲッティコードを生み出すという、我々が長年苦しめられてきた「開発のアンチパターン」そのものだ。AIエージェントを導入したからといって、この本質的な課題が消えるわけではない。むしろ、AIという高速な実行エンジンを導入したことで、仕様の不備が露呈する速度が劇的に上がったと言えるだろう。
テスタビリティという名の「AIへの招待状」
AIエージェントを実務に組み込む際、多くのエンジニアが陥る罠がある。それは「AIにすべてを理解させようとする」ことだ。CLAUDE.mdに長大な規約を書き連ね、エージェントのコンテキストを汚染し、結果として本質的な実装能力を低下させる。テラーノベル社の手法で特筆すべきは、CLAUDE.mdを「規約の置き場」ではなく「参照先へのポインタ」として機能させている点だ。必要なときに必要なドキュメントを読ませるというこの設計は、まさに疎結合なシステム設計の思想そのものである。
さらに、機械的に制御可能な規約は徹底してLinterに寄せるという姿勢も、シニアエンジニアとして強く共感する。デフォルトエクスポートの禁止やパスエイリアスの強制、アクセシビリティラベルの付与など、人間がレビューで指摘すべき「些末なミス」を機械的に排除することで、人間は「ロジックの正当性」や「UXの質」という、人間にしかできない高次元の判断に集中できる。これは、レビューの往復回数を減らすだけでなく、チーム全体の心理的安全性を高めることにも繋がる。
また、ロジックをUIから切り離し、純粋関数としてテスト可能な状態にするというアプローチは、TDD(テスト駆動開発)の再評価とも言える。UIコンポーネントをPropsのみを受け取る「純粋な表示器」に徹させ、状態管理を外部に追い出すことで、Storybook上での検証が極めて高速かつ確実になる。以下に、彼らが実践している規約と役割分担の構造を整理する。
| 工程 | 手法・ツール | 目的 |
|---|---|---|
| 計画 | superpowers / grill-me | 仕様の言語化と明確化 |
| UI検証 | Storybook (play関数) | コンポーネント単体のインタラクション確認 |
| 統合検証 | agent-device | 実機・Simulatorでの動作確認 |
| 規約管理 | ESLint / CLAUDE.md | 機械的な品質担保と参照の効率化 |
この構造において、agent-deviceは「最後の砦」として機能する。スクリーンショットから座標を推測させるような不安定な手法ではなく、roleやlabelを用いた要素指定を徹底することで、検証の精度を劇的に向上させている。これは、アクセシビリティ対応が単なる「弱者への配慮」ではなく、AIエージェントという「新しいユーザー」に対するインターフェースの最適化であることを示唆している。
エンジニアの価値はどこへ向かうのか
検証の自動化が進めば進むほど、皮肉にも「人間にしかできないこと」が浮き彫りになる。アニメーションのわずかな重さ、余白の違和感、指先で触れた時の「手触り」。これらは、どれほど高度なAIエージェントであっても、現時点では数値化・言語化が困難な領域だ。テラーノベル社の事例が示唆するのは、AIによる自動化は「エンジニアの仕事を奪う」のではなく、「エンジニアの仕事をよりクリエイティブな領域へ強制的に押し上げる」という事実である。
今後、EAS Simulatorのようなクラウドベースの検証環境が普及すれば、ローカルのMacに依存しないモバイル開発が現実味を帯びてくる。その時、我々エンジニアに求められるのは、コードを書く能力以上に「システム全体のテスタビリティを設計する能力」である。AIが自律的に検証を回せるようなコードを書くこと、AIが迷わないようなドキュメントを整備すること、そしてAIが検知できない「UXの微細な違和感」を鋭く見抜くこと。これらこそが、これからのシニアエンジニアの生存戦略となるだろう。
読者諸氏に問いたい。あなたの書いているコードは、AIエージェントが明日から引き継いでも、問題なくテストをパスし、リリースまで完遂できるだろうか?もし答えが「No」であるならば、それはAIの能力不足ではなく、あなたの設計が「人間というブラックボックス」に依存しすぎている証拠ではないだろうか。明日から、まずは1つの機能で良い。計画から検証までをAIに委ねることを前提とした設計を試みてほしい。そこで直面する「自動化を阻む壁」こそが、あなたが次に解決すべき技術的負債であり、あなたのエンジニアとしての市場価値を決定づける鍵となるはずだ。


コメント