Yuliia Apanasenko, CEO, フェノメノン・スタジオ Yuliia Apanasenko CEO, フェノメノン・スタジオ

AIがチームを苛立たせる理由 — とどうすればいいのか

ほとんどの技術では、使用するほど冷静に頼ることができます。しかし、AIツールでは、その逆が当てはまります。Stack Overflowは、49,000人以上の開発者に対する年次調査で、AIツールの使用率は84%に上昇したにもかかわらず、ツールの精度に対する信頼度は1年間で40%から29%に低下したと報告しています。この効果は私にもよく知られています。私たちのチームが開発でAIツールを初めて使用したとき、テクノロジー記者が書いていたように、作業が速くなる、苦労が少なくなるという「ワウ」効果はありませんでした。私たちの開発者たちはがっかりしました。AIは、レビューに長い時間を要し、結局、書き直す必要があった、平凡なコードを生成しました。チームはAIが時間を節約することを期待しましたが、代わりに余分な作業を得たのです。したがって、AIツールを日常のワークフローに組み込もうとした初期の試みの直後、チームは以前と同じように作業するよう戻りました。今日、同じツールは、私たちの開発者にとって、コードの記述とレビューの両方を高速化しています。より優れたモデルを見つけたのではなく、ツールと一緒に作業する方法を変更したためです。そこに至るまでに何が役に立ったのかを見てみましょう。AIが書いたコードが開発者を苛立たせる理由AIは、インターネット全体から膨大な量の公開コードに依存していますが、そのコードはまれに優れています。質は平均的で、モデルはその平均を再現します。しかし、「平均」は可能な限界ではありません。モデルがプロジェクトを理解するまで、それが生成するものです。プロジェクトの規約、コード構造、設計上の決定です。600人以上の開発者を対象とした調査で、Qodoは、AIコードの品質に不満を持つ開発者の44%が、コンテキストの欠如にそれを帰したと報告しています。那が生成される品質を平凡なレベルに留める原因です。良いニュースは、AIが受け取るコンテキストが、チームが完全に制御できる唯一の変数であるということです。ツールがプロジェクトをどれだけ理解するかは、モデルではなく、そこに何を与えるかによって決まります。2番目の理由は精神的なものです。作業の性質が変わります。AIがほとんどのコードを書いたとき、開発者の主な作業は、コードを書くことではなく、生成されたものを確認することになります。誰かの解決策を読み、選択肢を比較検討し、出荷できるものを決定することです。那は、自分でコードを書くこととは異なるスキルです。コードを書くことが好きな人にとって、それは簡単には得られないものです。GitHubの2025年のOctoverseレポートでは、開発者がAIと進歩したものは、コードの「著者」ではなく、その「クリエイティブディレクター」に近くなっていると説明しています。そこでの重要なスキルは、舵取りと検証です。しかし、その役割への道のりは、ミスや苛立から始まり、自分自身の仕事で成果を見て初めて信頼が生まれます。AIが苛立から効果的なツールになる理由私たちのチームがAIを初めて使用し始めたとき、開発者の中にはClaude Code、OpenAI Codex、GitHub Copilot、Gemini CLIなどのツールを使用する人もいました。各ツールは異なる結果をもたらしました。したがって、私たちがチームのAI使用方法を整理しようとしたとき、最初にしたことは、単一のツールに落ち着くことでした。これは私たちの慣行だけではありません。Linearのチームの話を見てみましょう。2026年1月まで、彼らは「誰でも自分に合った方法で作業する」という原則で動いていました。リーダーシップはそのアプローチを放棄し、開発者全員を単一の作業方法に切り替え、開発者にAIツールのみを使用してコードを書くように求めました。会社によると、平均的な生産性は、次の月にマージされたPRで30%、エンジニアごとのタスク完了数で33%増加しました。しかし、共有ツールだけではコードを改善できません。ツールを設定する必要があります。ルールを設定する必要があります。例えば、rules.mdのようなもので、コードを書く方法を規定します。次に、プロジェクトの典型的なタスクに合わせたカスタムスキルが必要です。同じことを繰り返し説明する必要はありません。最後に、エージェントを既存のコードベースに指向する価値があります。プロジェクトが書かれている方法を分析し、汎用的なものではなく、同じスタイルで新しいコードを生成します。ツールが受け取るコンテキストが多いほど、手動で書き直す必要は少なくなります。しかし、最も難しい部分は技術的なものではありません。コードの著者から評価者への移行は自然に起こりません。その移行には支援が必要です。最も直接的な方法は、トレーニングと認定です。例えば、私たちの場合、10人の開発者がツール提供者のパートナー・プログラムに参加しています。同時に、アドプション担当者がツールの結果を説明し、問題を解決する方法を指導しています。チームが調整された方法で作業するようになると、1つのボトルネックが残ります。レビューです。AIでそのボトルネックを強化する価値があります。エージェントは、すべてのプルリクエストを最初に通過し、明らかなものを処理します。ルーチン的なミス、スタイル、繰り返し、セキュリティの欠陥です。人間のレビュアーは、もう一切を見てはいません。アーキテクチャと重要な決定だけを見ています。Anthropicでは、エージェントを導入した後、実質的なレビューを受けたプルリクエストの割合は、16%から54%に上昇し、エンジニアはそのコメントに1%以下しか同意しませんでした。私たちにとっては、2、3日間かけて複数のラウンドで行っていたレビューサイクルが短縮され、シニアエンジニアのルーチン作業が軽減され、本当に難しい部分だけが残りました。ツールが最終的に、書き直す必要のない結果を生成し始めたとき、ツールに対する信頼も生まれました。AIツールへの信頼が実を結ぶ場所まず、コードの書き方です。ツールがプロジェクトを理解し、エージェントが最初のレビューを行うと、チームは同じ時間内に、より多く、より優れたコードを書くことができます。私たちの場合、AIツールは作業を約30〜40%高速化しました。そのほかにも、AIはオンボーディングを容易にしました。新しい人がプロジェクトに参加すると、経験豊富な人がプロジェクトのコード構成について数多くの質問に答える必要があります。現在、エージェントがその役割を果たします。プロジェクトが十分に文書化されている場合、新人は95%の質問を同僚ではなくエージェントに問い合わせます。ドキュメンテーションも同様です。粗いアーキテクチャのドラフトは、以前は数時間を費やしましたが、現在はエージェント自体によって書かれます。私たちの見積もりでは、約80%のドラフトが、十分なコンテキストを提供すれば、エージェントによって書かれます。人間が残したのは、リポジトリにないものです。決定事項、トレードオフ、専門知識です。同様に重要なのは、AIが何ができるかについて正直であることです。期待を膨らませることは、最初から失望を生みます。AIは、医療や金融データのコンプライアンスを担当しません。人間が署名し、会社が責任を負います。AIは、パートナーとの統合を高速化しません。電話や調整には数時間かかります。そのまま使えるAIは本当に苛立たしいのですが、それは、完成品として使われている場合のみです。苛立と実を結ぶ間の全ての違いは、AIの周りに何を構築するかです。共有された標準、プロジェクトのコンテキスト、開発者の新しい役割です。