毎日AIごった煮 · 2026-10-12

Robinがお届けする「しょっぱい話」の毎日AIごった煮です。

Amazonの倉庫ではすでに100万台を超えるロボットが昼夜を問わず稼働している。GitHubのインフラ障害ではActions、Pull Requests、Issuesが中断され、ステータスページは障害中にこれらのサービスの性能が低下したことを認め、議論は活動量の増加をAIコーディングエージェントに結びつけた。QGISのEnhancement Proposal #387は依然として提案段階で、AIによる支援を受けたコントリビューションをコードベースから締め出し、マージされるコードに人間の作者を明記することを求めている。

100万台を超えるロボットが、すでに倉庫で昼夜稼働している

Amazonほど多くのロボットを運用している組織は世界に存在しない。同社にはすでに100万台を超えるロボットが倉庫で昼夜を問わず稼働しており、毎日数千万件の当日配送・翌日配送の荷物を送り出している。100万台超というのは、すでに動いている数字であって、計画に書かれたままの目標ではない。今後数年、Amazonはこの隊列をさらに大幅に拡大する構えで、その手段は新しい工場を建て、能力の高いロボット労働者を量産させることだ。出典：Ars Technica

これだけの規模でロボットを導入しても、Amazonは依然として世界第2位の企業雇用主だ。2025年の年次報告書には、フルタイムとパートタイムの人間の従業員を合わせて150万人超と記されている。経営陣の説明では、ロボットの隊列が大きくなったことで、人間の従業員の負担は軽くなった。負担の軽減はタスクの移転によるものだ。フルフィルメントセンターで最も過酷なタスクをロボットが引き受け、そうしたタスクこそ、身体的疲労と怪我のリスクが最も高い種類のものだった。労働者支援団体や独立系の研究者は、AI駆動の倉庫自動化が、ロボットと一緒に働かなければならない人々にとって、必ずしも利益ばかりではないことを示す証拠がすでにあると指摘している。

違いは、機械が人にどれだけ近いか、そして作業のペースを誰が決めるかにある。ジョージ・メイソン大学の商学教授Brian GreenwoodはArsにこう語った。「過去100年間に私たちが見てきた自動化のほとんどは、通常、労働者から離れた場所で起きていました。高リスクのタスクを労働者から取り上げ、しかも身体的に労働者に近づかないやり方でそれを行うのです。」さらにこう続けた。「協働ロボットの登場はこの状況を本当に変えました。理由は2つあります。1つは身体的に労働者に近いこと、もう1つはロボットが作業のペースを規定する能力を持っていることです。」前者は距離の話で、機械が労働者のすぐ隣にいる。後者はテンポの話で、作業の速さをロボットが決められる。これは、危険なタスクを人のそばから取り除き、人と機械を近づけなかった過去100年のやり方とはちょうど逆だ。経営陣が強調するのは、最もつらい仕事が引き受けられたという点であり、研究者や労働団体が強調するのは、ロボットのそばに残された人々がそれによって利益だけを得たわけではないという点だ。

ステータスページは性能低下を記録し、議論は量をコーディングエージェントに帰した

GitHubのインフラ障害が、Actions、Pull Requests、Issuesの3つのサービスを中断させた。同社のステータスページは、障害中にこれらのサービスの性能が低下したことを認めている。この3つは開発者ワークフローの中核となる界面だ。ActionsはCI/CD自動化を提供し、それをトリガーするのはPull RequestsやIssues上で発生するイベントであり、そのトリガーはプラットフォーム全体の規模で動いている。ステータスページに記されたのは、障害中にこの3つのサービスの性能が低下したという事実だ。出典：GitHubステータスページ

この障害をめぐる議論は、根本的な圧力をプラットフォーム活動量の急激な上昇に帰した。その議論によれば、Actions、PR、Issuesの1日あたりの量は、約8か月で5000万から20億へと増えたという。別の説では、1日あたりのイベント量が約8か月で約5000万から約20億へ増えたとされている。3つ目の説は1日あたりの操作回数に着目する。コメントした人々は、この桁違いの跳躍をAIコーディングエージェントの大量出現に結びつけた。こうしたエージェントはプログラム的に動作し、コミット、ワークフロー、issueを大規模に生成し、ブランチ、コミット、issue、pull requestを、人間の開発者が自分でやるよりはるかに速い速度で作成する。

今回の障害が示したのは、スケーリング上の転換点だ。転換点とは、このプラットフォームのアーキテクチャはもともとこうした自動化された負荷に耐えるようには設計されておらず、それなのに今、エージェントが押し上げてくる量を受け止めなければならない、ということだ。コメントした人々は概ね、この負荷の急増をAIコーディングエージェントに帰した。結果を率直に言う人もいた。1日の操作が5000万から20億に増えれば、AI以前の前提の上に作られたシステムはほぼ確実に限界を超える、と。さらに先の規模を心配する人もいた。毎日数百件ものこうした自動化プロジェクトが動くようになる、と。少数ながら、依存を減らす道を指す人もいた。Forgejoのようなセルフホスト型の代替手段を使い、GitHubへの依存を下げるのだ。議論の中の5000万と20億という数字には「約」「報じられるところでは」といった余地が残され、期間も約8か月だった。

QGISの#387はまだ提案：マージされるコードには、誰が書いたかを明記せよ

QGISは、AIによる支援を受けたコントリビューションを自らのコードベースから締め出すことを提案している。提案番号はEnhancement Proposal #387で、現時点では依然として提案であり、すでに発効した禁止令ではない。挙げられている理由は、低品質なLLM生成のpull requestが増え続け、ボランティアのメンテナーにかかる負担が重くなる一方だということだ。提案は、分岐点をコントリビューターの責任に据えている。人は自分が提出したコードに責任を持つべきであり、AIツールを一律に敵視するのではない。マージ済みのコードに対して、2つの明確な基準を設けようとしている。1つは人間の作者を必ず明記すること、もう1つはレビューに明確な規則を持つことだ。出典：QGIS Enhancement Proposal #387

QGISは、GPLの下でメンテナンスされている無料のオープンソース地理情報システムだ。利用者はWindows、macOS、Linux上で地理空間データを閲覧・編集・分析できる。デスクトップGISの中で最も広く使われているプラットフォームの1つだ。Hacker Newsのこの議論は323ポイント、348件のコメントを集め、QGISをZig、NetBSD、GIMP、Gentoo、QEMUと並べて取り上げた。これらのプロジェクトはいずれも、LLM生成コードを含むpull requestを拒否している。AIツールでコードを生成するのはますます容易になる一方、外部からのコントリビューションを見極めるためのレビュー要員は限られたままで、両者は一緒には変わらなかった。そのためメンテナーは、AI生成のpull requestを制限するか、あるいは直接拒否するかして、レビュー時間を配分せざるを得なくなっている。

メンテナーは、すでにPRに埋もれていると言う。こうしたPRは見た目はそれらしいが中身が薄く、アカウントがレビューコメントに返信することはほとんどなく、一切返信しないことさえある。一方で、作業はコードを書くことから、コードが実際に何をしているかを検証することへと移った。コメントした人々の間では概ね、メンテナーが持続不可能なレビュー負荷を抱えており、その負荷はもっともらしく見えて実は薄いLLM生成のPRから来ている、という点で意見が一致している。Plotlyのメンテナーの1人は、応答しないボットの提出者による具体的な被害を描写している。開発者たちはもう1つ、特に頼りにならない点を指摘した。LLMは地理空間の数学になると、自信たっぷりに口を開きながら間違えやすいのだ。難しいのはもはやコードを書くことではなく、コードが実際に何をしているのかに自分を常に合わせ続けることだ。この検証コストが今、個人の開発とレビュアーの両方の作業を同時に支配している。プロジェクトそのものの長期的な維持が難しい状況では、証明可能な人間の作者であること、そして提出した後も最後まで付き合うことが、コントリビューションの最低ラインになるかもしれない。

100万台を超えるロボットがすでに倉庫で昼夜稼働しており、協働ロボットは労働者の近くに立ち、作業のペースを規定する能力を持っている。今後数年の新しい工場では、さらに能力の高いロボット労働者が生産され続ける。GitHubのステータスページが認めたのは、障害中にActions、Pull Requests、Issuesの性能が低下したということであり、議論は約8か月で約5000万から約20億への跳躍を、ブランチ、コミット、pull requestをプログラム的に生成するAIコーディングエージェントに帰した。QGISの#387は提案の段階にとどまっている。メンテナーは時間をコードを書くことから、見た目はそれらしいが中身の薄いpull requestのチェックへと移し、提案が求めるのはマージ時に人間の作者を明記することだ。3つの話の産物は異なるが、人間の側に残されているのは同じ種類のことだ。協働ロボットには作業のペースを規定する力があり、プラットフォームは当初この種の自動化負荷のために設計されていない量を受け止めなければならず、メンテナーはコードが実際に何をしたかを検証しなければならない。

🎧 本エピソードはポッドキャストでも配信中：每日AI乱炖 · 2026-10-12 を聴く。