反響の大きかったAI開発の記事を8本選びました。対象は10月12日から18日朝までに出た記事です。ブックマークやいいねの数は、18日朝の時点のものです。

今週は、AIで実装が速くなった分、要件の整理やレビューに人の手間がかかるという記事が目立ちました。時間がかかるのは、作るところより、人が決めて確かめるところになってきたとみています。

この記事でわかること

  • Claude Codeチームでは、承認する人を変更のリスクに応じて0〜2人にしています
  • すぅ氏は、プロジェクトでAIを使う人をまず1人に絞る始め方を勧めています
  • タンプでは、施策を比べる段階の工数見積もりを、エンジニアではなくDevinに任せました
この記事の目次（8節）
  1. リスクで決まる承認の人数
  2. プロジェクトでAIを使う人を、まず1人に絞る
  3. 工数の見積もりをDevinに任せ、エンジニアは作ると決まってから加わる
  4. 人の手を要所の承認だけに減らすソフトウェアファクトリー
  5. AIエンジニアリングのロードマップが口をそろえる「評価」
  6. Claude Codeとの過去の会話を探すclaude-recall
  7. Gemini 4 Argonに日本語を推敲させる
  8. LLMが書き間違えにくいブロックの閉じ方

リスクで決まる承認の人数

Claude Codeのコードの約90%は、Claudeが書いています。6月と9月を比べると、マージされたPRは2倍以上に増えました。また、リバートしたPRの割合は、6月の6割を下回りました。

リスクの高さは、変更の中身を見て分類器が決めます。低リスクなら、AIのレビューとセキュリティの検査が通れば、人の承認は要りません。中リスクは1人、高リスクは2人です。

ただし、人の承認を省けるのは、信頼できる作成者の一覧に載った人のPRだけです。

また、エージェントが出した承認は、人の承認として数えません。1

試し方は、当サイトの「Claude Codeチームがコードレビューの方法を公開」にまとめています。

プロジェクトでAIを使う人を、まず1人に絞る

全員にAIのアカウントを配り、共有会を1回開くと、3か月後に使っているのは数人だけになりがちだそうです。すぅ氏は、1つのプロジェクトで使い始めるときの順番を書いています。

まず1人を選び、その人がAIでプロジェクトを回せるようにします。ほかの人に広げるのは、そのあとです。選ぶ基準は、AIに詳しいことより、業務の中身を分かっていることです。

すぅ氏が作った進捗管理の仕組みでは、ほかのメンバーは週2回、Slackの質問に答えるだけです。返信をAIが読み、進捗の更新と日報づくりまで済ませます。2

工数の見積もりをDevinに任せ、エンジニアは作ると決まってから加わる

ギフトの通販サイトTANPを作るチームでは、以前は開発チーム全員で工数を見積もっていました。その結果が出るまで、施策の優先順位を決められませんでした。

いまは、事業部が決まったテンプレートで要求定義を書き、Devinが曖昧な点や抜けを指摘します。そのあとDevinが、コードから変更が要りそうな箇所を洗い出し、工数を見積もります。

事業部はこの見積もりで優先順位を決め、進めると決まった施策からエンジニアが加わります。時間がどれだけ減ったかの数字は、記事にはありません。3

人の手を要所の承認だけに減らすソフトウェアファクトリー

髙橋氏は、AIが要件定義からレビューまでを進め、人は要所で承認するだけの仕組み（ソフトウェアファクトリー）への移り方を話しています。

移る道筋は、8つの段階に分けています。要件が複雑でないチケットは、Notionで「オート実装」のフラグを立てて実装まで一気に進めるよう勧めています。

PRごとにプレビュー環境を立て、動作確認の証跡（スクリーンショットやAPIのレスポンス）をAIにPRへ貼らせる段階もあります。

最後に「おまけ」として、目指すKPIを挙げています。人が関わらずに終わったタスクの割合で、「無人化率」と呼んでいます。4 人のレビュー待ちで開発が止まる問題は、当サイトの「t-wada氏の『レビュー解体』」でも扱いました。

AIエンジニアリングのロードマップが口をそろえる「評価」

r.kagaya氏は、AIエンジニアリングに要るスキルを、Andrew Ng氏の連載、roadmap.sh、オライリーの『AIエンジニアリング』を並べて整理しています。3つに主に共通するのは評価だ、というのが同氏の見方です。

最初の一歩として勧めるのは、コーディングエージェントに足しているスキル（決まった作業の手順を書いた指示書）を1つ選び、評価することです。

過去の入力を10〜20件集め、出力を読んで失敗を種類ごとに分けます。lintやテストで見分けられないものだけを、LLMに採点させます（LLM-as-a-Judge）。5

Claude Codeとの過去の会話を探すclaude-recall

babarot氏が作ったclaude-recallは、Claude Codeとの会話をSQLiteに取り込み、検索できるようにします。会話はLLMで要約せず、プロンプトへ自動で差し込むこともしません。

Claude Codeは、何も設定しなければ30日で会話の記録を消します。取り込んでおけば、消えたあとのセッションも探せます。

検索はSQLiteの全文検索で、ベクトル検索は使いません。そのため、「認証エラー」で探しても、「401」としか書いていない会話は出てきません。6

Gemini 4 Argonに日本語を推敲させる

大賀氏は、Gemini 4 ArgonとGemini 3.8 Flashに日本語を一から書かせたり、推敲させたりして、出来を比べました。どちらのモデルも、技術記事を一から書かせると、6本すべてで出典の無い数字を言い切っていました。

大賀氏は、AIが言い切っている文でも、確かめて書いたとは限らないと注意しています。

慎重な言い方を含む文章を推敲させると、Argonは半分以上の回で原文をそのまま返しました。3.8 Flashは、どの回も手を入れています。

推敲した文を30組読み比べると、元の意味と語調を保つ点ではArgonが多く選ばれました。読みやすさでは、3.8 Flashが多く選ばれています。7

Gemini 4 Argonを誰がどのプランで使えるかは、当サイトの「Gemini 4 Argon一般提供」にあります。

LLMが書き間違えにくいブロックの閉じ方

kmizu氏は、LLMが学習していない小さな言語を自作し、文法はプロンプトの中で説明しました。そのうえで、ブロックの閉じ方によって、LLMが正しく書ける回数が変わるかを比べています。

入れ子が8段になると、end だけで閉じる文法では、試したモデルは1回も正しく書けませんでした。閉じるブロックの種類と名前まで書く end func foo では、24回すべて正解でした。

ブロックの中身を長くしても、正解の数は変わりませんでした。正解を減らしていたのは、入れ子の深さです。

ただし、試したモデルは1種類だけで、kmizu氏はこの結果を予備実験と位置づけています。8

先週の動きは「10月5日〜11日の技術トレンド」にまとめています。

出典

  1. Addy Osmani、Morgan Westlee Lunt、Qing Wang「How the Claude Code team does code review」（Claude Blog、2026年10月15日）（参照 2026-10-18）
  2. すぅ「AI駆動PMの組織でのはじめかた」（note、2026年10月17日）（参照 2026-10-18）
  3. 「人による工数見積もりをやめて、AIに任せることにした」（TANP Blog、2026年10月15日）（参照 2026-10-18）
  4. 髙橋誠二「コーディング自動化の次へ。人の介入をゼロにするファクトリーとサポートAIによる実践」（Findy AI x 開発組織サミット2026 の発表資料、2026年10月15日）（参照 2026-10-18）
  5. r.kagaya「改めて考える、AIエンジニアリングの今」（Zenn、2026年10月15日）（参照 2026-10-18）
  6. babarot「Claude Codeに過去の会話を思い出させる」（Zenn、2026年10月13日）（参照 2026-10-18）
  7. 大賀愛一郎「Gemini 4 Argonの日本語性能を検証してみた」（Zenn、2026年10月14日）（参照 2026-10-18）
  8. kmizu「LLMにとって書きやすい構文とは何か：`end` と `end func foo` を1,000回以上比べてみた」（Zenn、2026年10月16日）（参照 2026-10-18）