10月19日(月)のAIニュースRyokoの解説

公式発表Anthropic

1.Anthropic、株式5%を公益基金に拠出へ

要するにAnthropicが、株主の承認を条件に株式の5%を新しい公益基金へ拠出します。AIによる成長の利益を、株式の仕組みで社会へ戻す例です。

Anthropicが、公益のためだけに使う新しい基金へ、自社の株式を拠出すると発表しました。まず全株式の5%を、このAnthropic Public Benefit Fundに拠出します。ただし、この最初の5%の拠出には、株主の承認が必要です。

企業価値が50%増すごとに、2%ずつ追加できる

最初の5%に加えて、企業価値が基準から50%増すごとに、株を上乗せできる仕組みもあります。上乗せするかどうかは、取締役会の裁量で判断します。上乗せできるのは、そのたびに2%ずつです。統治のしかたやマイルストーンの詳細は、今後公表するとしています。

基金はLLC。使い道と、使わないこと

基金は非営利法人ではなく、Anthropicが全額出資するLLCとして設立します。伝統的な非営利団体への大口の寄付や、特定の人々への直接分配などに、柔軟に使えるようにするためです。使い道の例に挙げているのは、AIが雇用に与える影響への対応です。すでに約束している2億ドルに加えて、より大胆な手を打てるようにするとしています。一方で、保有する株はロビー活動や政治献金には使わないとしています。

既存の誓約と合わせ、約20%が公益へ

Anthropicには、創業者が持ち株の80%を寄付するという誓約もあります。社員の株式寄付をマッチングする制度もあり、社員の約半数が参加しています。新しい基金と合わせると、全株式の約20%が公益に向けられることになります。AIによる成長の利益を社会へどう戻すかを、株式の仕組みで示した例です。ただ、雇用への影響は想定する使い道の1つで、分配先や実施時期が確定したわけではありません。

出典を開く（Anthropic）スライドで見る

知見Claude

2.〈知見〉Claude Code、レビューを何層にも重ねる

要するにClaude Codeチームは、確認を何層も重ね、人の承認の数を変更の危険度で決めています。AIが書く量が増えたときの、確認と責任の整え方です。

Claude Codeチームが、自分たちのコードレビューの仕組みを解説しています。Claude Codeのコードは、約9割をClaudeが書いています。6月から9月にかけて、マージしたPRの数は2倍以上に増えました。一方で、取り消しが必要になった割合は40%以上減ったと報告しています。数値は同社の自己申告です。

PRの前後で、確認を何層も重ねる

やり方は、1つの関門に頼るのではなく、何層ものチェックを重ねることです。PRを出す前に、テストやビルドなど自分で確かめる手段をClaudeに渡し、結果を見せさせます。さらに別のサブエージェントが、新しい文脈で差分を確認します。PRには必ず、AIレビューとセキュリティレビューが付きます。指摘は直すか、理由を添えて解決します。すべて解決するまでマージできません。

人の承認の数は、変更の危険度で決める

人の承認の数は、変更の危険度で決めます。ドキュメントなど低リスクの変更は、自動チェックだけです。通常の変更は1人、課金や自動更新、CI設定のような高リスクの変更は2人が承認します。そして、AIが承認しても、人の承認の代わりにはなりません。

レビューする側も、毎日採点して見直す

レビュー役の質も確かめています。過去の障害を集めて、評価セットにしています。この評価セットで、レビュー役を毎日採点します。また、レビューのやり取りが延々と続かないよう、3往復したら進め方を見直します。

取り入れるなら、PRにテスト結果・リスク・戻し方

AIが書く量が増えたら、確認する手段と責任の所在も整える必要があります。記事の最後には、チームで取り入れるためのチェックリストがあり、短いCLAUDE.mdやREVIEW.mdを挙げています。まずは、PRのテンプレートにテスト結果・リスク・戻し方を書く運用から取り入れられます。

出典を開く（Claude.dev）スライドで見る

知見Google

3.〈知見〉Harness²、AIの道具と手順を試して改良

要するにHarness²は、モデルの重みを変えずに、周りの仕組みを試して改良する研究用フレームワークです。スキルや指示書の改善にも生かせる考え方です。

Google Cloud AI ResearchのHarness²は、エージェントの周りの仕組みを改良する研究用フレームワークです。モデルの重みは固定したままで、追加の学習はしません。周りの仕組みはハーネスと呼ばれ、システムプロンプトやガードレール、メモリ、ツールの使い方などを指します。これにサブエージェント、スキル、スクリプト、プラグインを加えた8つの要素を編集します。

仕組み: 案を出し、同じタスクで試し、組み合わせる

改良は3つの段階で進みます。まず、ハーネスの変更案を出します。次に、変更案を同じタスクで実際に動かし、結果の違いを比べます。そして、結果の違いから、有効だった変更を組み合わせます。この流れで、正解データがない未知のタスクでも、ハーネスを改善するとしています。

教訓をライブラリに残し、次のタスクへ

採用した設定と、いつ・なぜ有効だったかという教訓を、ライブラリに残します。この教訓を、次のタスクの改良に生かします。実際にタスクを動かす実行役には、OpenCodeとCodexを選べます。

報告された改善と、気をつけること

論文は、GLM-5とGemini 3.5 Flashで、WorkBuddy-Benchが最大11.5ポイント改善したと報告しています。LABでは、最大11.8ポイントの改善です。数値は論文の自己申告です。コードはApache 2.0の研究用で、Googleの公式サポート製品ではありません。スキルや指示書の改善を、実行結果で比べて残す考え方は参考になります。ただ、正解データのない課題では、比べる判断にも誤りがあり得ます。自動改良が常に正しいとは限りません。

出典を開く（Google Cloud AI Research）スライドで見る

知見Kuaishou

4.〈知見〉Kling 4.0、参照素材で映像を組み立てる

要するにKling 4.0では、参照素材と最大10枚のキーフレームで、長めの1シーンを狙いどおりに作れるようになってきました。1回の生成は最大30秒です。

KuaishouのKling 4.0は、動画を生成するモデルです。10月15日の発売を、IR資料で伝えています。9月30日付の公式ガイドは、画像や動画などを組み合わせる参照機能を説明しています。もう1つ説明しているのが、最大10枚のキーフレームによる演出です。

参照素材: 画像で外見、動画で動きや構図

参照機能のOmni Referenceでは、画像・動画・被写体・声を組み合わせて使えます。画像は外見、動画は動きや構図の手がかりに使います。人物の外見とカメラの動きを、別々の素材で伝えられます。参照素材は合計15点まで。画像10点、動画5点、被写体7点と、種類ごとの上限もあります。参照動画のテンポや構図を借りて、商品や人物を差し替える使い方にも対応します。

キーフレーム10枚で、最大30秒の1シーン

キーフレームは最大10枚まで指定でき、場面の変化や話の展開など、要所を決められます。1回の生成で、最大30秒の動画を作れます。プロンプトは、最大8,000トークンまで書けます。短いカットをつなぐのではなく、絵コンテや参照素材から長めの1シーンを狙いどおりに作れるようになってきました。

使う場所と、確かめておくこと

AIエージェントからは、Kling MCPとCLIを通して使えます。企業や開発者向けのAPIは、近く提供するとしています。4KやHDRの提供時期は、公式資料の間で説明に差があります。解像度やHDRは、利用画面の条件を確かめてから制作しましょう。

出典を開く（Kling AI / Kuaishou）スライドで見る

知見GitHub

5.〈知見〉GitHub、会話から複数リポジトリを調べる

要するにGitHubのSlack・Teams連携で、1つの会話から複数のリポジトリを扱えます。チャットでの相談を、そのまま課題の整理や調査へ進められます。

GitHubのSlack・Teams連携では、1つの会話から複数のリポジトリを扱えます。同じ会話のまま、作業するリポジトリを切り替えられます。@GitHubは、メッセージの途中に書いても反応します。

公式の例: 課題作成からPR、調査まで

公式の例では、スレッドの内容をもとに課題を作れます。フロントエンドのリポジトリでバグを直してPRを開く、という頼み方もできます。全リポジトリから自分のPRを出して、対応が必要なものを教えてもらうこともできます。フロントとバックエンドの両方のコードをまたいで、問題を調べることもできます。

会話を文脈にして、依頼は具体的に

共有したSlackのメッセージやスレッドを、文脈として参照できます。エラーを減らし、中断からの復帰も改善しています。使うには、Copilotの利用プランが必要です。チャットでの相談を、そのまま課題の整理や調査へ進められます。依頼文には、対象のリポジトリと、作成・調査してほしい範囲を具体的に書くと、確認しやすくなります。

出典を開く（GitHub Changelog）スライドで見る

知見

6.〈知見〉AIで内製する範囲は、保守まで含めて決める

要するにAIで内製が合理的な範囲は広がっても、監督・保守・結果の責任は自社に残る、と論じる記事です。誰が直し続けるかまで比べる材料です。

コーディングエージェントの登場以降、「SaaSの死」や「内製の黄金時代」が語られるようになりました。一方で、AIへの懸念で年初に急落したSaaS株は回復し、SaaSの売上も成長を続けているという指摘があります。この記事は、AIで自作できるのに、なぜ企業はSaaSにお金を払い続けるのかを問います。そして、内製と外製の境界の引き方を、取引と契約の経済学から考えています。

経済学の見方: 内製に向く仕事、外製に向く仕事

記事は、経済学の3つの理論を参照しています。コースの企業理論、ウィリアムソンの取引費用理論、ハートらの不完備契約理論です。これに沿うと、自社固有の知識への依存が強く、変化を予測しづらく、契約で決めきれない仕事ほど、内製に向きます。逆に、汎用的で、仕様や品質を明確にでき、代替業者も多いものは、外製に向いています。

AIで変わること: 変更は速く、責任は残る

記事によると、人への外注では、仕様変更のたびに再見積もりや交渉が要り、数週間かかっていました。AIへの指示も、ある意味で外注ですが、変更は数分でやり直せます。予測できない変化への対応が安くなれば、内製が合理的になる範囲は広がります。外注先への報酬には、不具合への対応や技術の進歩への追従、セキュリティの更新を引き受けてもらう対価も含まれています。AIで内製すれば、そのリスクはすべて自社に残ります。監督できる人がいなければ、責任を取る相手のいない外注になりかねません。

それでも外部のサービスが有利な領域

たとえば、月額3000円のサービスでホームページを賄えるなら、自作するメリットは小さいといいます。AWSのようなクラウドも、AIでコードを安く書けても、計算資源や冗長化、運用まで安くなるわけではありません。専門事業者が設備を大規模に共有することで生まれる、分業と規模の利点は、コーディング能力だけでは埋まりません。さらに、提供する側もAIで効率化できます。値下げや、同じ価格でより良いサービスを出す余地が生まれます。

判断の材料: 誰が直し続けるかまで比べる

記事は、AIが少なくとも一部の領域で、内製が合理的になる範囲を広げると見ています。その広がり方を決めるのは、自社固有の事情、変更の頻度、外部と調整する負担、AIを監督できる人材の有無、そして市場の価格です。この記事は、作れるかに加えて、誰が直し続けるかまで含めて考える材料になります。まずは、既存サービスの利用料と、自社の監督・保守に必要な時間を比べてみましょう。

出典を開く（@iototaku）スライドで見る