AIリストラに共通する構図と「経済の悪循環」の懸念

Oracle、Amazon、Cloudflareなどで相次ぐAI関連の人員削減を眺めると、企業ごとの事情は違っても共通の構図が見えてくる、とする分析が出た。AIへの投資を加速させるため、あるいはAIで代替できた業務を切り落とすために人を減らす――その判断自体は各社で合理化できるが、連鎖の行き着く先には雇用と消費の冷え込みがある、と指摘されている。

このリストラ連鎖が「経済の悪循環（スパイラル）」を引き起こし得るという見方が、別の記事でより踏み込んで論じられた。AIで人を減らせば賃金総額が減り、消費が縮む。消費が縮めば企業の収益環境が悪化し、さらにコスト圧力が強まるという経路だ。技術の生産性向上が長期的には経済を支える面もある一方で、移行期には需給の悪化が自己増幅するリスクがあり、短期的なコスト削減の判断が中期的な足元を固める構造になりかねない、とされている。

なぜ重要かというと、AI導入の「成功」を個社の効率改善で測っていると、経済全体への波及を見落とすからだ。規模が大きくなるほど、リストラの自己相乗効果を制度で吸収できるかが問われることになる。

エージェントの「スキル」を装うマルウェア、静的スキャンをすり抜ける

Claude CodeやCodexなどで使われる「スキル」は、中身がMarkdownの手順書と小さなスクリプト一枚で、GitHubから拾ってフォルダに置くだけで動く手軽さがある。しかしその分、悪意あるスキルはエージェントと同等の権限でシェルやファイル、保存済みの認証情報にアクセスできてしまう。こうしたエージェントスキルを狙った攻撃と、それを見つけるはずの静的スキャナを調査した研究が相次いで発表されたという報道がある。

注目すべきは、防御側の実態だ。見つける役のスキャナは、実際にはほとんど機能していないという指摘が出ている。ファイルとして置くだけで発動する仕組みの上に、検出が追いついていない。つまり「リポジトリから拾ったスキルを安易に置けば動く便利さ」と「検出できない現状」の落差が、そのまま攻撃面になり得る。

エージェント系の安全装置や偽装事件は既に何度か話題になっているが、今回は「検出が機能していない」という防御の弱点が研究ベースで示された点が新しい。外部のスキルを導入する際は、出所の確認と最小権限での検証が前提になりそうだ。

LLMレビューが終わらないのは直し方のせい？ 108ラウンドの検証

ある長い運用手順書を、提供元の異なる2つのLLMに繰り返しレビューさせた実験が報告された。指摘を裏取りし、本当の問題なら直す。直した文書をまた同じ2つに読ませる。これを108ラウンド続けたが、2つが同時に「指摘なし」になった回は一度もなかったという。

一つ直すと次の指摘が出、それも直すとさらに次が出る。ここで筆者が疑ったのは、「もう既存の欠陥を見つけているのではなく、自分の修正が新たな欠陥を作り、それを次のレビューが指摘しているだけではないか」という仮説だ。もしそうなら、レビュー後半ほど『修正が原因の指摘』の割合が増えるはずで、これを停止条件の目安に使えるのではないか、と分析している。

同時期に、AIにJiraのチケットを拾わせ24時間自動開発させた事例も報告された。席を立った状態で最後までやらせたところ、戻ってきたのは67件のレビュー指摘だった。肝はAIの能力そのものより、人間が座っている間に曖昧さを暗黙に吸収していた部分が、无人化するとレビューの手戻りとして表面化した点だという。

2つの事例に共通するのは「AIの反復作業をどこで止めるか」という問いだ。指摘が減らないからといって無限に直し続けると、修正そのものがノイズを生む。停止条件を人間が設計しないと、レビューは収束しない。

巨大LLMを自宅GPUクラスタで ― Kimi K3のローカル実行報告

LocalLLaMAコミュニティで、Kimi K3を自宅のGPUで動かした報告が上がった。ポイントは、GPUが1台に収まらないため2つのクラスタをllama.cppのRPC接続でまたがらせて実行した点だ。メモリに載りきらない分はディスクへオフロードしながら動かし、最終的には1台に集約してRPCなしで動かせれば速度が2〜3倍になると見ている。今は低精度のIQ1_M量子化で試し、将来的にはより高精度な量子化へ、そしてQwen3.8やDeepSeek V4 Pro、GLM5.3など同等サイズでより高速なモデルの登場に期待を寄せる内容だった。

ここで鍵になるのが「量子化」だ。LLMをメモリに載せるため、パラメータの精度を落として軽くする技術だが、専門書を開くとFP32やINT4といった数式がいきなり並ぶ。初心者向けに数式を避け、「つまりどういうことか」を腹落ちさせる形で整理した解説も出ている。巨大モデルを自宅で動かすには、この精度と容量・速度のトレードオフを理解しておく必要がある。

オープン重みモデルのローカル実行自体は継続的な話題だが、今回は「複数クラスタをRPCで束ねてまでKimi K3を動かした実体験」と、その前提となる量子化の入門が揃った。ハードウェアと精度設定を工夫すれば、データセンター級のモデルも自宅で形になることが分かる。

レガシー47万行をAIで移すと、いくらかかるのか

Strutsベースの基幹システムMifos（約47万行）をAIで移行した連載で、企画会議で必ず出る「で、うちのだといくらかかるの？」に実測で答える試みが報告された。

前段で「壁剥がし」と呼ぶレガシー層の除去を8層・4コマンドで進め、数十分から1時間・約42.5ドルで47万行の49.7%がコンパイル可能な状態になったという。さらに公式生成のテスト58件、業務ルール台帳42枚、依存関係マップ（124モジュール・1,032辺）など、後工程の前提になる材料も揃った。この実測をもとに、規模別の見積もりレンジを出す構成だ。

なぜ重要かというと、AI移行は「できるかできないか」より「いくらで、どこまで進むか」が実務の関心だからだ。1時間で約半分がコンパイルを通るという数値は、同種のレガシー案件を前にした現場にとって、現実的な見積もりの参照点になり得る。