この動画では、AIコーディングアシスタントの導入前に技術チームが検討すべき重要な質問について解説している。単純にツールを選ぶのではなく、まずエンジニアリングインフラの基盤を整備することの重要性を強調し、具体的な問題解決の目標設定、既存の開発プラクティスの評価、ワークフローとの適合性、成功指標の設定など7つの事前検討項目を提示している。さらに、すでにAIコーディングアシスタントを使用しているチーム向けに、効果的な活用と問題の診断方法についても7つの評価ポイントを説明している。
AIコーディングアシスタント導入前の重要な検討事項
私には非常にシンプルな仮説があります。これは人気がないかもしれませんが、真実です。コーディングアシスタントは、それが良いものであれ悪いものであれ、あなたの開発プラクティスを加速させます。言い換えれば、あなたが持っているエンジニアリングインフラのプラクティスに巨大なロケットエンジンを結び付けて、「さあ、もっと速く、もっと多くのことをやってくれ」と言っているようなものです。
もしエンジニアリングインフラ層やベストプラクティス層に何らかの弱点があるなら、Claude CodeやCodexを追加するという選択は、結果的にマイナスになってしまいます。はい、そう言いました。結果的にマイナスになるのです。そんなことになってほしくありません。なぜなら、実際に成果を上げているチームもいるからです。
最近Redditで「こうやって私たちはFANGをバイブコーディングした」という記事がバイラルになりました。それは何についてだったと思いますか？すべてを魔法のように修正してくれるバイブコーディングツールセットについてではありませんでした。それは重要なエンジニアリングインフラの決定についてだったのです。今日はそこに焦点を当てたいと思います。
今週のトップニュースでCodexが話題になっているので、私たちはCodexがスライスしたパン以来の最高のものである理由を深掘りすることもできます。開発に携わる人なら誰もが「Codexを使うべきか？Claude Codeを使うべきか？」と話しています。
あなたは間違った質問をしています。ほとんどの場合、正しい質問はエンジニアリングインフラ層にあります。適切なエンジニアリングインフラの質問をした場合にのみ、ツールの選択にたどり着くことができるのです。
導入前に検討すべき7つの質問
テクニカルリーダー、テクニカルチームメンバー、ビルダー、コーダー、バイブコーダーとして、ツールを選ぶ前に自分自身に問いかけるべき具体的な質問をお教えします。これらを最初に考えることで、ツールを使う時に実際に速くなることができ、遅くなることはありません。
質問1：具体的に何の問題を解決しようとしているのか？
実際にこれに答えられる人はほとんどいません。試してみてください。ボイラープレートコードのスピードアップですか？ジュニアのオンボーディングですか？バグや反復的なタスクの削減ですか？それとも他の何かですか？
「エンジニアリングチームの生産性を向上させる」というような曖昧な目標があるなら、申し訳ありませんが、あなたはC-suiteに長く座りすぎています。具体的な内容が必要です。このツールが私たちのエンジニアに何をしてくれるのか、なぜなのかという具体的な期待を述べる必要があります。
個人のビルダーなら、「私はビルダーで、DevonやClaude Codeを使うことで時間を取り戻せる。会議中でも、ツールが勝手に構築してくれる」というのもあります。それは公正で、具体的な目標です。その目標を最適化することについて話し、ツールなどについて話すことができますが、解決しようとしている具体的な問題や設定している具体的な目標がなければ、すでに間違った方向に向かっています。
会社が大きくなればなるほど、これを行うのが難しくなることがわかります。大きなチームを持つ大企業は、具体的にどの問題を解決しようとしているのかを言うのに実際に苦労することが多く、そこにたどり着くには多くの作業が必要です。
質問2：すでに増幅する価値のある強力なエンジニアリングプラクティスを持っているか？
前提条件を見てください。コードベース全体で一貫したコードパターンがありますか？最新のドキュメントがありますか？実際のレビュー文化と厳格なPRレビューがありますか？誇りを持って支持できる設計ドキュメントがありますか？
これらがなければ、どのエージェントを選んでも、どのツールを選んでも、AIはあなたがやっていることを悪化させる可能性が高いです。家を整理する時間を取って、選択するものが構築できる基盤を持つようにする必要があります。
AIはその点で驚くほど脆弱です。多くのことで素晴らしいですが、あなたが規律正しくあることを必要とします。AIがサポート的な方法でインフラとして組み込まれるためには、良いエンジニアリングプラクティスを持つ必要があります。
多くの会社がそうではありません。そして再び、これは大企業にとって挑戦的なものになります。一人の小さなコーダーなら、「はい、私はこのマークダウンファイルにすべてのコーディング決定を保持し、Claude Codeにチェックしてもらって完了です」または「すべてのプルリクエストを自分でレビューします。私は良い仕事をしていることを知っています」と言えます。
チームが大きくなればなるほど、これはより複雑になり、実際にこれについて考える必要があります。複雑さは非線形にスケールし、数人の開発者やマルチチーム規模を超えると、ツール評価がはるかに複雑になります。
質問3：ツールはワークフローと技術スタックに適合するか？
これは複雑ですが、チームがすでに何を使っているかを自問する必要があります。Cursorを使っていますか？VS Codeを使っていますか？何でもいいですが、コードホストは何ですか？GitHubにいますか？場合によってはターミナルにいますか？
実際のワークフロー互換性がどのようなものかを考える必要があります。ここで追加の課題をお話しします。エンジニアリング team外のワークフロー互換性について考える必要があります。これは、エンジニアリングプラクティスに関する2番目の質問に戻ります。
特にサブエンタープライズレベルの場合、従来のエンジニアではない人々がコード関連のアイデアを持ち、潜在的にコード関連のプロトタイプを何らかの形でコードストリームにプッシュしたいと思う世界に住んでいると仮定してください。本番環境ではないかもしれません。エンジニアがレビューする必要があるかもしれません。
しかし、単一の創設者レベルを超えたチームを持つ企業では、コーディングエージェントの使用により、非コーダーがプルリクエストを提出している企業があります。その世界で持続するのに十分強力なエンジニアリングプラクティスがありますか？通常は本番コミット権限を持たない人々が、ある程度のコーディング作業を行い、それをエンジニアリングアーキテクトに渡すことを可能にするツールがありますか？
私の知る限り、その世界には真のプラグアンドプレイはありません。あなたのユニークな指紋を見て、互換性のあるツールスタックが何かを決める必要があります。
CodexとClaude Codeをレビューしていて注目したことの一つは、Codexが暗黙的により大きなチームを中心とした重力を前提としているように見えることです。Codexの多くは、私のコードに提出されるPRを自動的にレビューできるかどうかに関するものです。Codexはすでにそこにあり、GitHubに入ることができ、PRをレビューし、レビューを書き上げることができ、さらには問題を修正し、対処することもできます。
一方、Claude Codeは、あなたがターミナルで作業し、エンドツーエンドで構築しており、問題を修正し、コード以外のことにも取り組んでいるという考えをより前提としています。一方が良くて一方が悪いということではなく、エコシステムでの焦点が異なるということです。
レバレッジがどこにあるかを考える必要があります。Claude CodeにPRをレビューしてほしい場合、それは絶対に可能だからです。人々はいつもそれをやっています。同様に、単一のビルダーもCodexをいつも使っています。それを誓う人々を知っています。
一つのツールがあらゆる使用例に完璧だということではありません。モデルの能力の観点からだけでなく、プロンプトとの一致度から、モデルとの快適さの度合いから、さらにはトークンバーンの観点からだけでなく、エコシステムの観点から考える必要があります。どのように適合するかです。
質問4：成功をどのように測定するかを知っているか？
コードベースで起こる変化をどのように追跡するかを知っていますか？どの指標があなたにとって重要ですか？「ああ、たくさんのコミットがあって、それが私たちのやり方だ」とか、コード行数のような虚栄の指標を持っていますか？
AIが書いたコード行数についてCTOに自慢し、CTOがそれを要約に書き上げ、CEOがそれをツイートするつもりですか？ちなみに、それは実際に起こっています。それは本当に指標ですか、それとも虚栄の指標ですか？コード行数を持つだけでは、どのエンジニアも実際の生産性にとってひどい指標だと言うでしょう。
価値をどのように測定したいかを考えてください。恐ろしい話の一つ、これはあなたを怖がらせるためではなく警告するために言いますが、これらの決定をうまく行ったと思っても、私がLLMクリープと呼ぶものの継続的な影響を実際に考慮していない可能性があります。
つまり、LLMはかなり良いということです。LLMはあなたのコードベースを理解します。エンジニアリングインフラが挑戦に対応できると思いますが、チーム全体がLLMコーディングをチェックし、レビューし、誰もが何が起こっているかを知り、誰もがベストプラクティスに従い、LLMが独自に漂流していないという継続的なリズムがありません。
時間が経つにつれて、エンジニアリングマネージャーや創設者の時間をますます多く、LLMが提出したものをレビューするために費やすことになります。LLMが効果的に意図しないアーキテクチャ決定を行い、他の誰かがそれを解きほぐさなければならないため、コードベースがますます理解困難になり、リーダーシップや戦略的思考のための時間が少なくなります。
私のアドバイスは、多くの目があることの方が良いということです。複数の目があり、複数の人と構築している状況にいる場合は、それらの目を活用し、誰もがAIコードが誰かがそれを見て「はい、これはアーキテクチャ的に正しい。はい、これは実際に動作する」と言わない限り本番環境に行かないという期待を持つべきです。
それが常にそうではありません。「私たちはそれをしない。動作すると信じている」と言う人がたくさんいます。それで構いません。そして、いくつかの場合では、あなたは非常にしっかりしていて、非常にクリーンで、すべてが非常によく文書化されていて、小さなチームで非常に完璧で、それで逃げることができるかもしれません。
しかし、私はそれらの完璧な1%のためにここにいるのではありません。部分的なドキュメンテーションの現実に住み、誰もがベストを尽くし、誰もが締切を満たそうとし、誰もが新しいベストプラクティスに従ってコーディングしようとし、時々忘れてしまう他の誰もののためにここにいます。
コードベースの定期的なレビューとLLMパフォーマンスの定期的なレビューを持つことで、LLMの利益を維持するエンジニアリングプラクティスを実際に導入できる場所にいるべきです。これが成功を測定できるかということです。時間をかけて変化を実際に追跡できますか？
質問5：セキュリティとデータプライバシーが慎重に検討されているか？
ベンダーが提供している利用規約、モデルメーカーが提供している利用規約に満足していますか？IPリークをチェックしましたか？生成されたコードの脆弱性、コンプライアンス問題、そのコードにミスがある場合に生成される責任について確認しましたか？
エージェントを成功させるには、QAと本番コードの両方で、はるかに高いバーが必要になります。はい、彼らははるかに速くコードを書くことができます。セキュリティ研究者の中には、それは脆弱性をはるかに速く製造する方法に過ぎないと言う人もいます。そして、はい、それらの中には脆弱性をキャッチするものもあります。
実際、それはOpenAIがCodexについて指摘したことの一つで、コードの脆弱性をキャッチするのが得意で、OpenAI自体が本番環境に行く前のQAプロセスの一部としてCodexを使用しているということです。
CodexとClaude Codeが価値を追加しないと言うためにここにいるのではありません。これら2つの会社は自分たちの製品をドッグフーディングしており、そこから価値を得る方法を見つけています。しかし、それらが銀の弾丸ではないことを指摘するためにここにいます。Codexについて詳しく話したいなら、まずこれらのエンジニアリングインフラプラクティスについて話さなければなりません。
質問6：実際に賛同を得ているか？
再び、大きな企業、非線形問題空間では、これはより困難になります。ジュニアエンジニア、シニアエンジニア、プリンシパルがいて、私が話したような非技術的な人々もいるかもしれません。プロンプティングに関する教育をどのように計画していますか？AI出力のレビューをどのように計画していますか？ジュニアの学習使用がどのようなものかを理解することをどのように計画していますか？
ジュニアがコードが実際にどのように動作し、システムコンポーネントがどのように組み合わさるかを理解し、AIに過度に従うことにならないようにするためです。これを実際に学び、設定して忘れるという誘惑に陥らないために、リソース、お金、また時間をどのように予算化しますか？
これらのツールは設定して忘れるのが魅力的に簡単だからです。物事をするように指示するだけで、もしかしたらコストが今日請求されないかもしれません。請求書が6ヶ月後に来るかもしれません。今日それを行うために規律正しくなければなりません。
質問7：価格を超えた総コストは何か？
セットアップ、メンテナンス、コンテキストエンジニアリングコスト、悪い出力の修正を見る必要があります。大きなチームがある場合、実際にパイロットを行うことは価値があります。なぜなら、実際にこの個別の2ピザチーム、この小さなチームのために2、3ヶ月間で価値がどのようなものかを見ることができるからです。
それはまさに多くの企業で見られるパターンで、小さなグループにロールアウトし、テストし、学習を収集し、その後より大きな道筋がどのようになるかを理解します。再び、小さなチームなら、方向転換するのは非常に簡単です。これは双方向のドアです。今日Codexを試して、「ああ、これの方が良い感じだ」と言い、Claude Codeを捨てます。明日Claude Codeを試して、彼らが何か新しいものをリリースしたときに、「ああ、これの方が良い感じだ」と言い、Codexを捨てます。
大きなチームにいるときは、それほど簡単ではありません。そのようには機能しません。
すでにAIコーディングアシスタントを使用している場合の7つの評価ポイント
セットアップ時に尋ねるべき基本的な質問について話しました。また、プルリクエストやRedditを見ていると、多くの方がすでにAIコーディングアシスタントを使用していることもわかります。
この部分では、AIコーディングアシスタントの現在のユーザーとして、AIが実際にあなたを助けているか害しているかを理解し、それをトラブルシューティングして現在のAIコーディングアシスタント実装を最大限に活用する方法についての質問を扱います。
最初の7つと同様に、7つを通していきます。意図的にダブリング効果を作成しているので、これが実装前から実装へのマッピングを見ることができます。
評価ポイント1：AIがコードベースの不整合を増幅しているか？
これは一貫したインフラ層を持つという考えに直接マップしませんか？持続的なアンチパターンが提案にあるかどうかをチェックして確認する必要があります。間違った出力がある場合、それらが傾くかどうか、特定の方向に間違って行くかどうかを監査する必要があります。アンチパターンが消えるように、特定の方法でドキュメント標準を微調整する必要があるかどうかです。それはあなた次第です。それをチェックする必要があります。
評価ポイント2：AI出力をレビューしてテストしているか？
準備すべきこととして話しました。しかし、実際にやっていますか？実際に説明をスキップしていますか？推奨されているエッジケーステストをスキップしていますか？「説明してください」と言って、「まあ、それはドキュメンテーションで十分だ」と言っているだけですか？
AIコーディングアシスタントからのAI出力を所有できると感じていますか？それが本当の基準です。それを支持して「このコードは私のものです」と言えるなら、まあ、十分公正ですが、誰もがそれをするわけではありません。
評価ポイント3：コーディングアシスタンスを進める際にプロンプティングやコンテキストが問題になっているか？
曖昧なプロンプトで曖昧なコードを取得している場合、チームに明確な仕様がありますか？チームに設計ドキュメントがありますか？チームに例がありますか？これがインフラ層に直接戻ることがわかりますか？
コードベースでの小さな増分変更に対して小さな増分変更をテストすることで、実際にこれを診断できます。ドキュメンテーションを変更し、プロンプトを変更し、コードベースが改善されるかどうかを確認し、インフラ層のために修正する必要があるテストケースがどこにあるかを理解し始めることができます。これは実際に、意図的であれば修正を特定できるものです。
評価ポイント4：あなたが持っているツール制限によるエラーがあるか？
ツールインフラが実際に検討されていますか？モデルの弱点がありますか？Codexが強調したことの一つは、一部のコーディング問題は非常にトークン効率的な外科的変更を必要とし、一部のコーディング問題は非常にエージェント的な長文形式の変更を必要とするというコーディング問題の非線形性を理解しており、それらがより良いというメトリクスを生成したということです。
あなたの走行距離は異なるかもしれません。それらに同意するかどうかを確認する必要があります。しかし、ポイントは、ツールがセットアップと一致するかということです。必要に応じてモデルを切り替えることができるセットアップがありますか？実際に持っているコードベースのサイズや特定のニッチドメインや実際に持っている特定のニッチ言語を理解することができるセットアップがありますか？
その例は、Claude CodeとCOBOLです。COBOLを使う人なら、いつか試してみてください。どう思うか見てください。
評価ポイント5：チーム使用状況はどうか？
チームはエンジニアリングが上達していますか？非エンジニアはエンジニアリングプラクティスを学んでいますか？実際に何かを壊さなかったように、本番前に行われた変更でお互いをキャッチする頻度と、本番後に物事をキャッチして何が起こったのかと疑問に思う頻度はどれくらいですか？
一般的な新人ミスがどれくらいの頻度で発生し、それらが繰り返され続けていますか？人々が理解せずにコピペする頻度はどれくらいですか？人々がツールに思慮深いフィードバックを実際に与えない頻度はどれくらいですか？ここにはチーム文化的なことがあり、それは実際にリーダーシップが強化すべきことです。
評価ポイント6：重要なことを測定しており、それを追跡して実際に価値を提供していることを示すことができるか？
これには2つの重要な要素があることを提案します。一つは、エンジニアリングが行っていることを、重要な実際のビジネス使用例、重要なビジネスプロジェクト、収益、コスト効率に結び付けることです。エンジニアはそれについて神経質になることを知っていますが、ゲームに利害関係を持つ必要があります。
もう一つは、先行指標が確実であることを確認することです。LLMレイテンシがどのようなものかを理解していますか？本番環境にあるものがある場合、エッジケースをテストする方法と、それらのエッジケースがLLMから本番環境で実際にどのように現れるかを理解していますか？
ドキュメンテーションが十分にクリーンであることを示し、コードパフォーマンスで評価を実行する方法を理解していますか？「はい、コードプロンプトからコードの品質は非常に高いです。それを言う人間評価者がいて、PRコメントの数が減り、PRの品質が上がり、本番環境で見たバグの数が減っている」と言えるような、指摘できる具体的なものもあります。
評価ポイント7：失敗が続く場合、問題は準備が不十分だったということか？
これは、このビデオの最初に戻って飛び込むということを意味するか、それともスタックに根本的な何かがあるということですか？コードベースコンテキストの実装方法について考える必要があるかもしれません。コンテキストを検索するエージェント検索アプローチが必要かもしれません。RAGがあなたにとって正しいアプローチではないかもしれません。
何であれ、AIを責めると仮定する前に、規律正しい監査について考えてください。規律のないチームは、それが安くて簡単だからAIを責めます。規律のあるチームは具体的な問題の根本原因を突き止めて、実際に価値を得ます。
まとめ
これらは、人々が「Codexのニュースが出た、ネイト。Codexのニュースが出た。Codexで何をすればいいのか？」と言って急いで入ってきたときに、何度も何度も言わなければならないことです。
まあ、これが私の言うことです。まずこれらのインフラの会話をしましたか？これらのインフラの会話をしてください。それらは重要です。それらは重要なものを構築するのに役立ちます。
これらは、AIが実際に日常的に行っているすべてのプラクティスを増幅するときに、夢見ているものではなく、実際に行っているものを増幅するために設置しなければならない会話です。これらのプラクティスが設置されていれば、悪いものではなく良いものを増幅するかもしれません。実際に遅くなるのではなく速くなるのに役立つかもしれません。物事を壊すのではなく、より高品質のコードを提供するのに役立つかもしれません。
理解してもらえると思います。インフラが重要です。これらの質問を真剣に受け止めてください。どのツールを選ぶかについて複雑な会話をする前に、通らなければならない最初のゲートとしてそれらを受け取ってください。
別の機会にCodexについて詳しく取り上げます。
コメント