はじめに#
ベルリンで開催された WeAreDevelopers World Congress 2025 から戻ってきたばかりですが、ヨーロッパ中や世界中から集まった多くの開発者と出会い、大いに刺激を受けました。もちろん、今年のメインテーマはAIでした —— AIはまさに至るところに存在しています！今やクラウドにも、PCにも、サングラスにも、トースターにも、キッチンの流し台にも、果てはトイレットペーパーにまでAIが搭載される時代です。誰もAIからは逃れられません……あのJavaScriptフレームワークの増殖スピードですら、AIの進化の速さには太刀打ちできないほどです！人類はもうおしまいです！！！>.<
……というのは冗談です（あるいは、あながち嘘でもないかもしれませんが！）。確かに今は少々不気味で先が見えない時代です。テクノロジー業界は大きく変容しています。「AIによって生産性が向上した」「AIが人員を代替できる」といった名目のもと、世界中のテック企業で大規模なレイオフが相次いでいます。これがレイオフの真の理由なのか、それとも別の思惑を隠すためのスケープゴート（口実）にAIが使われているだけなのかは、パブでビールでも飲みながら話すべきネタであって、このブログの本題ではありません。ただ確かなのは、今まさに大きな地殻変動が起きているということです。
私がこれまでの人生と経験から学んだ大切な教訓の一つに、「自分がコントロールできないものに思い悩んでも仕方がない」というものがあります。AIの台頭は不可避です。それなら、将来自分たちの仕事がどうなってしまうのかを不安がるのではなく、「今日、いまの自分の仕事を向上させるためにAIが何をしてくれるか」に目を向けてみませんか。ピンチをチャンスに変える、いわゆる「物事をポジティブに捉える（コップに水が半分も残っていると考える）」アプローチです。少し肩の力を抜いて、開発プロセスに「バイブス（vibe）」を取り入れた、現代の開発者ワークフローがどうあるべきかを一緒に考えてみましょう。
これは、私が過去4週間にわたって実際に実践し、非常に高い効果を実感しているワークフローです。もちろん、まだ発展途上で完璧なものではありませんので、あくまで参考程度にとどめてください。とはいえ、この領域の進化スピードは目覚ましく、今後さらに洗練されていくはずです。
優先順位付けに対する2次元アプローチ#
実際の「AIネイティブ」な働き方に踏み込む前に、私がこれまでのキャリアで7年以上にわたって使ってきた優先順位付けモデルを簡単にご紹介します。これは ThoughtWorks 在籍時にアジャイル変革（Agile transformation）プロジェクトで学んだ手法を、自分自身のニーズに合わせてカスタマイズしたものです。エンジニアとステークホルダー双方の関係者をひとつの部屋に集めて議論し、バックログを消化していく論理的な実行順序を導き出します。
このモデルは、技術的確実性（technical certainty）とビジネス価値（business value）という、直交する2つの軸に基づいています。
「技術的確実性」とは、その機能の実装手順や道筋がどれだけ明確になっているかを表します。技術的確実性が高い場合、実装に必要な全工程（またはほぼすべてのステップ）がすでに判明している状態です。逆に技術的確実性が低い場合は、どう実装すべきか見当がつかないか、最初の数ステップ程度しか見えていない状態を意味します。
「ビジネス価値」とは、チームの目標達成においてその機能がどれほど重要であるかを表します。ビジネス価値が高い機能はビジネスの成功に直結するクリティカルなものであり、ビジネス価値が低い機能は「あれば嬉しい（nice to have）」程度にとどまります。
この演習の最終的な目的は、**「すべてが最優先」**という膠着状態を打破することです。たとえ建前としてはすべてが重要だとしても、それらを2軸上に並べて可視化することで、最も頑ななステークホルダーであっても他の優先事項との相対的な位置関係を見直しやすくなります。また、ビジネス価値が同じでも技術的確実性が異なるタスクにも、実行すべき順番が存在します。まずは「手近な成果（low-hanging fruit）」を先に片付けることで、チームは残りの機能についてスパイク（技術調査）を行い、不確実性を減らす（＝技術的確実性を高める）ための時間を稼ぐことができるのです。
では、この優先順位付けモデルが「AIネイティブな働き方」とどう結びつくのでしょうか？私は自分自身を「何体ものAIエージェントを率いる上司」だと捉えています。自分自身のバックログに優先順位をつけ、どのタスクにどのツールを割り当てるかを差配するのです。深く関与してこだわりたい（「コミットしている」）機能であれば、同期的に対話しながら進めることを優先し、そうでなければバックグラウンドで動く非同期ワーカーにタスクを委任します。
基本的な「AIネイティブ」ワークフロー#
システムの新しい機能を実装する場面を考えてみましょう。作業の進め方には、対話型モード（インタラクティブ）とバッチモード（非同期・投げっぱなし／fire-and-forget）という2つの主要な運用モードがあります。どちらを選択するかは、その機能をどう実装するかについての技術的確実性と、現時点でそれにどれだけ深くコミットしたいか（ビジネス価値）に大きく依存します。
たとえば前回の記事（Julesを使ってこのブログに特集記事を追加した方法）でも触れた、このブログのトップページに「おすすめ記事（featured post）」セクションを実装したときのケースを考えてみましょう。着手した当初、私は特集記事セクションの実装方法について何も知りませんでしたが、「実現したいゴール」のイメージだけは持っていました。どの技術を使うべきかも、コードのどこに手を加えればよいかも分からなかったため、これは典型的な「技術的確実性が低い」課題でした。一方で、「トップページが格段にプロフェッショナルになり、読者にとって魅力的になる」という明確な仮説があったため、自分にとっての「ビジネス価値」は非常に高いものでした。
このような状況では、フィードバックループを極力短くするのが自然な選択となります。AIが提案してくる変更を一つひとつ即座に確認し、正しい方向へと軌道修正しながら導いていく必要があるからです。逆に、優先度の低いタスクであればフィードバックループが長くても困らないため、バッチモード（非同期処理）に任せるのが適しています。
低〜中程度の技術的確実性、または高いビジネス価値 = 対話型モード（同期）#
技術的確実性が低い課題では、正しいゴールに到達するためにより手厚い監督が必要となるため、CLIツールを用いた対話型のプロセスを好んで使用しています。現在私がメインで使っているツールは、Google からリリースされてまだ2週間ほどながら、すでに開発者の世界で大きな話題を呼んでいる Gemini CLI です。
Gemini CLI は、AI を組み込んだ REPL（対話型実行環境）のようなコマンドラインアプリケーションです。プロンプトを入力すると CLI が即座に応答を返してくれます。Model Context Protocol（MCP）をサポートしているため、返ってくるのは単なるコードやテキストにとどまらず、実質的に何でも操作可能です。コーヒーの注文からデータベースの更新に至るまで、あらゆるタスクに CLI を使えます。もちろん本来の主なユースケースはコーディングですが、エンジニアの探究心（遊び心）はとどまるところを知りません。:)
Gemini CLI には自動化を想定した YOLO モードも用意されていますが、正直なところ、人間の監督なしにすべてを任せられるほどにはまだ信頼していません（これについては後述します）。そのため、解決策を決める前に問題領域をブレインストーミングし、探索したい場面で CLI を使うようにしています。機能の設計プランを作らせたり、実装の選択肢を調査させたり、あるいはとりあえず一気に実装させてみることもあります —— そして、その初期実装から得られた知見をもとに一度コードを破棄し、綺麗な状態から作り直すのです。これがいわゆる「プロトタイピング」です。
手動でコーディングして納得のいくプロトタイプを作るのに何度も試行錯誤するのと同様に、適切なプロンプトにたどり着くにも何度か試行が必要です。決定的な違いは、手動なら1つのプロトタイプに1週間かかっていたところを、わずか30分から1時間程度で完了できる点です。1日で3〜4通りの異なる実装パターンを試すことができ、その日の終わりには十分な比較データをもとに、確信を持って1つの設計を採用できるようになります。
技術的確実性が低い課題に CLI を使う最大の理由は、フィードバックループがほぼ瞬時に回るためです。仮説を検証し、粗い部分を手直しして、すぐに次のイテレーションへ進めます。発生するタイムラグは、モデルがリクエストを処理するわずかな時間だけです。
高い技術的確実性かつ低〜中程度のビジネス価値 = バッチモード（非同期）#
前述のとおり、技術的確実性が高い課題とは、実装に必要なすべての（またはほぼすべての）手順がすでに見えている状態を指します。手順が分かっているのであれば、自分で手を動かす代わりに AI に実行を任せてしまえばよいため、作業が格段にスムーズになります。
このような場面こそ Gemini CLI の YOLO モードの出番と思えるかもしれませんが、実はこの用途にはさらに適した Jules というツールが存在します。Jules は今年の Google I/O で発表されたツールで、瞬く間に私の一番のお気に入りとなりました（Gemini CLI は僅差の2位です）。
Jules は GitHub と連携してバックグラウンドでタスクを実行してくれる非同期エージェントです。正直に告白すると、最初に Jules に触れたときは詳細をよく読まず、動作の遅さに少しやきもきしていました。しかししばらくして、「バックグラウンドにタスクを投げておき、自分はPCから離れて別の作業や私生活に集中できることこそが本質」なのだと気づいたのです。
Jules は GitHub に接続されているため、プロジェクト全体のコンテキストをすでに把握しています。そのため、「依存パッケージのバージョンアップ」「単体テストの実装」、さらには「特定のバグの修正」といったメンテナンスタスクを任せることができます。ここで重要なのは、フィードバックループが長い（すぐに結果が返ってくるわけではない）ため、手順やゴールがステップ・バイ・ステップで明確に見えているタスクに限定して利用するのが賢い使い方だということです。
高い技術的確実性かつ高いビジネス価値 = 対話型モード（同期）#
上記の分類を見て、「高い技術的確実性」と「高いビジネス価値」が組み合わさった領域を、なぜあえて同期的な対話型モードに指定しているのか疑問に思われたかもしれません。その理由は極めて単純で、私自身がその成果（高いビジネス価値）に強くこだわっており、自分の目で直接進捗を見届け、最短で完成させたいからです。パラメータの重みが同等であれば、技術的確実性よりもビジネス価値が常に優先されるべきだと私は考えています。
低い技術的確実性かつ低いビジネス価値 = 本当にやるべきか？#
これらは普段、バックログの底に埋もれて忘れ去られてしまうようなタスクです。AI 以前の時代であれば放置一択でしたが、AI が使える現代なら、ふと思い出したタイミングで Jules にタスクを投げ、不確実性の低減やビジネス価値の発掘に向けた可能性を探らせてみます。投げる側の認知的負荷（認知コスト）はごくわずかなので、思いつく限りの簡単なプロンプトで Jules タスクを立ち上げても、失うものは文字通り何もありません。仮に大した成果が得られなかったとしても、どうせ自分では手をつけなかったタスクですから、少しでも有益な知見が得られればそれだけで儲けもの（プラス）です。
例外#
もちろん、どんな優れたプロセスにも例外はつきものです。高いビジネス価値を持つタスクであっても Jules に委任するケースがあり、それは主に「そうする以外に手がない状況」です。例えば以下のような場面です：
- カンファレンスなどのイベントに参加中で、新しいアイデアを思いついてもPCを開いて実装できないが、手元にスマートフォンはあるとき
- 移動中でネット回線が不安定、あるいは極端に遅いとき
- スーパーのレジ待ちの列でやり残したタスクを思い出し、帰宅後すぐに取り掛かれるよう下準備（キックスタート）をしておきたいとき
要するに、「進捗ゼロ」か「Jules にタスクを投げる」かの2択であれば、迷わず Jules を起動して作業を進めてもらうということです。
また、ここまでの説明では従来の IDE がワークフローのどこに位置づけられるのかについて触れていませんでした。IDE を捨て去ったわけではありません。現に、このブログ記事も VS Code で執筆しています。私は IDE による手動編集を「ラストワンマイル」や「最終的なコードの仕上げ」のために残しています。注意点として、「バイブコーディング（vibe coding）」のセッションの真っ最中に手動で細かな編集を加えるのは避けてください。LLM が文脈を見失って脱線する原因になりやすいからです。しかし、プロセスの最終工程として手動調整を行うのであれば、何の問題もありません。
番外編：不確実性を減らすためのTips#
あるトピックについて調査したいものの、自分のコードベースにどう組み込むかさえ見当がついていない段階もあるでしょう。Gemini CLI や Jules に無理やりコーディング以外の調査タスクをさせようとするのは、壁にネジを留めるのに金づちを使うようなものです。このような純粋なリサーチが必要な場面では、代わりに Gemini Deep Research を使うのがおすすめです。Jules と同様、Gemini Deep Research も非同期で動作するため、バックグラウンドでリサーチを開始させておき、自分は普段の作業を続けられます。
もし PC の前にいて結果を待ちたくない（即座に対話したい）なら、Google 検索のグラウンディングを有効にした通常の Gemini を使うのも非常に効果的です。ただしどちらのツールも出力がやや冗長になりがちです。私のようにせっかちな（あまり待つのが得意でない）方は、得られたリサーチ結果をそのまま NotebookLM に投入し、要約させたり、移動中に聴けるポッドキャスト（音声解説）を生成させたりすると、情報収集がさらに捗ります。
結論#
優先順位付け演習に基づく AI ツールの選定プロセスと作業モデルは、以下のように要約できます：
- 高い技術的確実性 ＋ 高いビジネス価値 = Gemini CLI による同期プロセスまたはペアプログラミング。細かな仕様確認には検索グラウンディング付き Gemini を活用。
- 低〜中程度の技術的確実性 ＋ 高いビジネス価値 = Gemini CLI による同期プロセス ＋ 技術的確実性を高めるための非同期リサーチ。
- 高い技術的確実性 ＋ 低〜中程度のビジネス価値 = Jules による非同期プロセス。必要に応じて Deep Research を併用。
- 低い技術的確実性 ＋ 低いビジネス価値 = 原則として着手しない（どうしても進めたい場合は、Jules や Deep Research を活用してどちらかのパラメータ向上を試みる）。
このワークフローについてどう思われますか？ぜひ下のコメント欄でご意見やご感想をお聞かせください！
