Atsushi Nakatsugawa
February 07, 2026
1 min read
February 07, 2026
1 min read
Share
Cut code review time & bugs by 50%
Most installed AI app on GitHub and GitLab
Free 14-day trial
AI Subscription: It's not enough to buy an AI subscriptionの意訳です。
10年前、私はドイツのある企業でDevOps変革を主導しました。クラウド、コンテナ、そして多くの自動化です。移行で一番大変なのはツールだと思っていましたが、実際は違いました。Kubernetesの設定やCI/CDパイプラインではなく、人々に変化を信じてもらい、新しいプロセスを受け入れてもらうことが最も難しかったのです。手動テストから自動テストに移行することで、リリースまでの時間を数か月から数週間に短縮し、数百万を節約できましたが、それは人の心を動かした後の話でした。
AI導入も同じ話です。時代が違うだけです。
毎週のように、Google や Claude のサブスクリプションを購入し、「魔法」を期待したチームと話します。結果は、ぎこちないオートコンプリートと、混乱する出力の山でした。「AIツールを持っている」ことと、「AIのおかげでより良いソフトウェアをより速くデリバリーできる」ことの間には、ベンダーが語りたがらないほど大きなギャップがあります。
そこで、AIの支援する開発スタイルを導入する際に見落とされがち、または完全に誤解されがちな落とし穴を集めました。これから導入を考えている方、あるいは試したものの期待外れだった方に向けた内容です。
銀の弾はありません。あらゆるプロセス変更には理解と計画が必要です。これは、多くの失敗（そして多少の涙）から生まれたプレイブックだと考えてください。
F1カーを買うことはできますが、サーキットトレーニングなしでUberドライバーを運転席に座らせても、オフィスには着かず、病院行きになる可能性が高いです。
問題点:
AIの利用は簡単に見えます。ボットとチャットして終わり、という印象です。しかし、このシンプルさは非常に欺瞞的です。プロンプトはスキルであり、どれだけ高価な Opus 4.5 を使っていても、悪いプロンプトは悪い出力にしかなりません。AIの使い方（そして、使わない判断も含めて）を理解するには時間がかかります。それがなければ、誰も運転できない車にお金を払っているのと同じです。
簡易診断:
エンジニアに聞いてみてください。「システムプロンプトとは？ コンテキストポイズニングとは？」。ポカンとされたらスキルギャップがあります。コンテキストエンジニアリングを理解することが、AIツールから実際の価値を引き出す鍵ですが、ほとんどの開発者は教わっていません。エージェントと、その裏で使われているLLMモデルの違いを理解していない人もまだ多くいます。
有効な対策
簡単なスキル評価からはじめましょう。すでにAIツールを効果的に使っている人がいれば、その人たちはこの学びでとても重要です。
学習時間をきちんと確保し、社内外でコースを実施します。「自分で何とかしろ」は研修ではありません。
社内のアーリーアダプターに主導してもらいます。外部トレーナーよりも、同僚からの推薦の方が効果的です。社内ランチ勉強会は、ベンダーのウェビナーよりも機能し、しかも安価です。
早期の導入者と初心者を組ませます。自社プロジェクトの実課題を扱うペアプログラミングは、これ以上ない学習方法です。
「昨日XYZを全員分買った。文句言わずに使え。」
問題点:
経営層がマーケティングデモだけを見てツールを選び、一夜で導入を強制するパターンです。大抵、チームの実際のワークフローとの検証は行われていません。開発者は、自分たちは無視されたと感じます。ツールはスタックやワークフロー、個人の好みに合わないかもしれません。抵抗が生まれ、やがて問題はツールではなく自律性の話になります。結果、導入は失敗し、予算は無駄になり、チームは苛立ちます。
さらに状況を悪くしているのが、ツールの選択肢が非常に混沌としている点です。AIネイティブな IDE（Cursor、Windsurf）、IDE向け拡張（Roo Code、GitHub Copilot、Cline）、特定プロバイダへの依存性、サブスクリプション型か従量課金型か、チャットUIかインライン補完かエージェント型ワークフローか。ここに万能な正解は存在しません。「XとYを使えばいい」と言ってほしいなら申し訳ありませんが、それはしません。エージェントを売りたいわけではありません。チームがみんなで決めるべき判断です。
簡易診断:
匿名アンケートを実施します。開発者はAIツールに満足しているか、選定に関与できているか。「会社が決めた」では普及は促進しません。
有効な対策
チームが現状、何を使っているかを確認します。業務や個人開発でAIを深く使っている人は確実にいます。
5分ずつのライトニングデモで、メンバーにツールを紹介してもらいます。
時間を投資して選定し、複数案を見せた上で、チームに発言権を与えます。
最適解はスタック、ワークフロー、予算、個人の好みに依存することを受け入れます。
AIは自信過剰なインターンのようなものです。もっともらしく聞こえますが、致命的に間違っていることがあります。
問題点:
AI生成コードは一見正しく、表面的なレビューを通過しがちです。私たちのデータでは、AI生成コードは人間が書いたコードより 1.7倍バグが多い ことが示されています。セキュリティホール、性能問題、エッジケースなどの微妙な問題が潜んでいることがあります。他人のコードを検証するのは認知的に難しく、AIが生成するコード量が増えるほど、その負担は増加します。その結果、検証を省略したり、浅く済ませたりしがちです。「見た感じ良さそうだから大丈夫だろう」がデフォルトになり、十分な検証なしにマージされます。この点は、コードを書くより読む方が難しい という最近の記事で詳しく説明しています。
バグに関する話:
早く見つけるほど修正コストは安くなります。チケット対応中に気づけば、担当者は要件や文脈を理解しているので、修正は数分で済みます。しかしPR、さらに本番に進めば、修正には数時間から数日かかり、顧客の不満が発生します。正式なPRレビュー前に問題を発見する方が安く、速いのです。プレコミットレビューは過小評価されがちですが、AI駆動開発では非常に重要です。今後の記事で詳しく扱います。
簡易診断:
インシデントレポートとPRメトリクスを並べて見てください。AI利用が増えてから本番バグが増えていれば、盲信が入り込んでいます。逆に本番は安定しているが「修正要求」が激増しマージまでの時間が倍になっていれば、レビュアーがAI生成の問題を必死に拾っているということです。
有効な対策
開発者は「書いて即プッシュ」ではいけません。AIが書いたものは、できるだけ早い段階で徹底的にレビューしましょう。
プレコミットレビューを標準にし、研修や文化に組み込みます。
Linterだけでなく自動チェックを活用しましょう。AIが書いたものを別のAIにレビューさせましょう。十分な無料枠のあるツール もあります。
健全な懐疑心を育てましょう。AIを疑うことが目的ではなく、信頼する前に検証することが目的です。
高速道路に車が増え、全員が同じ一車線の出口に殺到している状態です。
問題点:
AIコーディングツールで、個々人の開発速度は上がります。しかしPRはレビュー待ちで積み上がり、レビュアーがボトルネックになります。AIは大量のコードを簡単に書けるため、PRは大きくなりやすく、レビューは難しくなります。その結果、デリバリーが遅延したり、本番事故が増えたり、あるいはその両方が起こります。
簡易診断:
直近3か月でコード量が倍増し、平均レビュー時間も増えていればボトルネックであると言えます。逆にコード量が増えてもレビュー時間が同じなら、それもまた危険です。速くて浅いレビューは事故につながります。速く、かつ深いレビューが必要です。
有効な対策
即時フィードバックが得られる 一次AIレビュー を自動化しましょう。
早いフィードバックなら、作者はまだ文脈を覚えています。数時間・数日後の人手レビューでは半分忘れています。
人手レビュー前に、作者が自動フィードバックを解消しましょう。
人間のレビュアーは、設計、ロジック、ビジネス文脈など判断が必要な部分に集中しましょう。
フィードバックループが速いほど、マージも速くなります。
注意：AIレビューは大きな時間短縮と高速化をもたらしますが、適切な人手レビューを置き換えるものではありません。
コンテキストのないAIは、設計図のない請負業者のようなものです。何かは作りますが、たいてい必要なものではありません。
問題点:
AIツールの性能は与えられるコンテキスト次第です。人間はSlackの会話や雑談で不足分を補えますが、AIはできません。その代わり、自信満々に不足分を「発明」します。それは望ましくありません。
ツールが分断されると、引き継ぐ度にコンテキストが失われます。暗黙知はAIの文脈に入りません。
簡易診断:
直近5件のIssueを見てください。受け入れ条件や明確な問題定義がありますか。それとも「バグ修正」と期限切れリンクだけですか。ドキュメントはいつ更新されましたか。READMEの中に、2年前に捨てたフレームワークが書かれていたら、AIは17世紀の地図で航海している状態です。
有効な対策
良いIssueは受け入れ条件を含んでおり、良いプロンプトになります。
IssueをPRにリンク し、コンテキストをAIに流し込みましょう。要件や受け入れ条件の検証も可能になります。
AIが参照できるコードベースドキュメントを整備しましょう。
チームの知識を アクセス可能な形 で残しましょう。
「この移行で誰かがクビになる。」
問題点:
恐怖とストレスです。若手は職を失う不安からAIに過度に依存し、シニアは専門性が軽視されると感じて抵抗します。「自分の方が速い」という声もよく聞きます。AIは開発者を置き換えませんが、そう考えている経営層がいるのではと恐れています。チームが心から支持しない限り、良い結果は出ません。
フリードリヒ大王（後のドイツ帝国を築いたプロイセン国王）は、兵士は敵より将校を恐れるべきだと言いました。それは18世紀の歩兵には有効だったかもしれませんが、現代のソフトウェアチームには最悪の格言です。恐怖はトライする気持ちをなくさせ、問題を隠し、優秀な人材を去らせます。あなたはプロイセン軍を率いているわけではないのです。
簡易診断:
ボトムアップで進めましょう。チームに主導権を持たせ、実験して失敗し、改善を繰り返しましょう。賢い人を雇っているなら、指示は不要です。そうでないなら、AIも助けになりません。
有効な対策
AIは代替ではなく増幅器だと明確に伝えましょう。
アーリーアダプターに価値を示してもらいましょう。経営層の言葉より説得力があるはずです。
判断力や創造性、理解力といった人間の強みを評価しましょう。
ツール選定とワークフロー設計にチームを参加させましょう。
懐疑的な意見にも耳を傾けましょう。そこには妥当な懸念点が多く含まれているはずです。
これらの課題は相互に関連しています。研修不足は盲信につながり、トップダウン導入は人の問題を生み、コンテキスト欠乏はレビューのボトルネックを悪化させます。
最も痛いと思われるポイントから始めてください。多くのチームではスキルギャップ、盲信によるバグ流出、レビュー滞留のいずれかでしょう。
個々の課題は深ぼっていく価値があります。今後の記事で、プレコミットやPRレビュー自動化、変革マネジメントを扱っていきます。重要な洞察は10年前と同じです。ツールは些細な問題であり、本当に変革が必要なのは習慣、文化、ワークフローなのです。
ぜひフィードバックをお願いします。AI導入の成功談や失敗談を教えてください。こちらへご連絡ください。すべて拝読し、返信します。
自動コードレビューの実例を見たい方は、 Langflow や Clerk が、どのように CodeRabbit を使って人手レビュー前に問題を検出しているかをご覧ください。
