我々はCodexとどう向き合うべきなのか
この記事は、すでにCodexやClaudeCodeなどのAIコーディングツールを実際に使い始めているエンジニアに向けて書いている。「期待ほど効率が上がらない」と感じている人や、運用の型を模索している個人開発者を想定している。導入方法や基礎理論は扱わない。ひとりのエンジニアが数ヶ月間Codexと向き合って得た、実践的な運用知見を語る。 数ヶ月で変わったこと まず、ここ数ヶ月でAIコーディングツールの使い方が大きく変わったという話からしたい。 数ヶ月前のClaudeCodeガードレール戦略全盛期と比べると、隔世の感がある。あの頃は、AIが暴走しないように制御する、余計なことをさせないようにガードレールを張り巡らせることに頭を悩ませていた。Kiroが登場したときも、その延長線上にあった。 しかしGPT-5-Codexの登場で、その流れが変わった。 コンテキスト詰め込み時代の終わり 何が変わったの
なぜSerenaを使うとAIのコード編集が正確になるのか？
なぜSerena MCP Serverを使うとAIのコード編集が正確になるのか AIがコードを理解する二つのアプローチ 現在のAI開発ツールは、コードを理解するために主に二つのアプローチを活用している。一つは「意味的な類似性」で関連コードを発見するRAG（Retrieval-Augmented Generation）、もう一つは「構文的な構造」を解析するLSPといった技術だ。重要なのは、これらは対立する技術ではなく、それぞれに強みがあるということである。 CursorやGitHub Copilotといった主流のAI開発ツールは、RAGによる埋め込み検索を中心に据えている。コードを数値ベクトルに変換し、意味的に類似したコードを高速に発見する。「ユーザー認証の処理を探したい」といった曖昧な要求に対して、authenticationやlogin、validateといった概念的に関連するコードを幅
AI駆動で開発するときに重要なこと（設計と考え方）
問題：AI開発における「8割の罠」 AI駆動開発で最も注意すべきは、AIにいかに良い成果物を作らせるかではなく、AIにいかに既存の良い実装を破壊させないかである。 典型的な悪循環 AIに開発を指示 成果物の8割は良い感じ、残りの2割に問題あり 2割の改善を指示 問題の2割は改善するが、元々良かった8割の一部が改変・破壊される 結果、全体の完成度は8割から進歩しない この「部分最適化による全体破壊」のループが、AI駆動開発の最大の落とし穴だ。 解決策：破壊を防ぎ、品質を向上させる4つのアプローチ 1. コンポーネント化と責務の分離 なぜ有効か： 変更の影響範囲を物理的に制限できる 実装例（MVVMパターン）： ViewModelとViewを明確に分離 「View側だけ修正して」という指示でViewModel側の破壊を防げる ViewModelに「何を表示する画面か」というコンテキストが残る
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
