GenAI週刊 2026年03月28日号
今週のAI・コーディング関連の重要な動向をお届けします。
今週のハイライト
今週のGenAIコーディング界は、「成熟」と「反動」という二つの力が同時に表面化した一週間だった。
一方では、ハーネスエンジニアリングがCLAUDE.mdの静的な指示を超え、Skills・Hooks・Channelsという動的制御アーキテクチャへと進化を遂げた。コンテキストエンジニアリングは100Mトークンの拡張と1/12圧縮という両面から最適化が進み、国産LLMはRakutenAI・PLaMo・Sakanaがそれぞれ独自のニッチを切り拓きつつある。AIコーディングの技術基盤は、明らかに成熟のフェーズに入った。
しかし他方では、ガートナー調査で消費者の50%がAIを拒否し、BlackRockのラリー・フィンクはAIが格差を拡大すると警告した。LiteLLMのサプライチェーン侵害はAIエージェント時代のセキュリティ脆弱性を白日のもとに晒し、Taktのマルチエージェント協調は5回の失敗を経てようやく実用的な設計原則にたどり着いた。非エンジニアのClaude Code活用事例は華々しい成果を見せる一方で、「プログラミングのデモクラタイゼーション」が美談だけでは語れない複雑さも浮き彫りにしている。
この「成熟」と「反動」は矛盾ではなく、技術が本格的に社会実装されるフェーズで必然的に生じる緊張関係だ。ハイプが去った後に残るのは、セキュリティ・組織・倫理という「面倒だが不可避な」課題群であり、今週の記事群はまさにその課題に正面から取り組む具体的な試みの集積である。
1. ハーネスエンジニアリング成熟宣言：CLAUDE.mdからSkills・Hooks・Channelsへの大転換
今週、ハーネスエンジニアリングは単なるバズワードから実装パターンへと決定的に転換した。CLAUDE.mdによる静的な指示から、Skills・Hooks・Channelsを組み合わせた動的な制御アーキテクチャへ――Claude Codeの進化は「AIエージェントをどう飼いならすか」という問いに対する具体的な回答を次々と提示している。5段階の習熟度モデルからコグニティブ・アーキテクチャまで、開発者がエージェントを「同僚」として扱うための設計言語が急速に整備されつつある。
ハーネスエンジニアリング ― AIエージェントが自律的に動ける開発環境の設計
https://ai.acsim.app/articles/harness-engineering-2026
AIエージェントによるコード生成が当たり前になった今、現場で本当に起きていることは何か。コードの「量」は爆発的に増えたが、レビュー負荷が追いつかず、デリバリーがかえって不安定になる――いわゆる「生産性のパラドックス」だ。本記事は、この構造的な課題に対して「ハーネスエンジニアリング」という設計思想を提唱する。
ハーネスエンジニアリングとは、AIエージェントの出力を意図した方向に制御し、ミスを自動で検出・防止するフィードバックループを備えた環境を設計することだ。OpenAI、Anthropic、Stripeなど先進企業はすでにこのアプローチを実践している。リポジトリ内にAGENTS.mdなどエージェント専用のドキュメントを構造化して配置し、リンターやCIをエージェントが自律的に修復プロセスを回せる「決定論的なゲート」として再設計する。
ここで問われるのは、エンジニアのマインドシフトだ。「どう書くか（How）」への固執を手放し、「何を作るか（What/Why）」を明確にする。そしてAIが80%まで自律的に完遂できる強固な開発基盤を構築する。ハーネスエンジニアリングは、AIの能力を引き出すと同時に、人間の本質的な判断にリソースを集中させるための設計戦略でもある。
Anthropicはこの設計思想をさらに高度な実装に落とし込んでいる。
長時間実行型アプリケーション開発のためのハーネス設計
https://www.anthropic.com/engineering/harness-design-long-running-apps
AnthropicのLabsチームが、長時間稼働する自律型コーディングエージェントの性能を引き上げるために開発したマルチエージェント・ハーネスの設計知見を共有した。
核となるアイデアはGAN（生成対抗ネットワーク）に着想を得た3エージェント体制だ。コードを生成する「Generator」、それを批判的に採点する「Evaluator」、複雑な要件を分解する「Planner」を分離することで、単一エージェントでは困難だった品質向上ループを実現している。特に重要なのは自己評価バイアスの克服で、AIは自身の出力を過大評価する傾向があるため、独立したエージェントに「独創性」「技術的精緻さ」などの具体基準を与えて評価させることが不可欠だった。
また、長時間タスクで発生する「コンテキスト不安」――早期に作業を切り上げようとする傾向――への対策として、コンテキストのリセットや自動圧縮を導入している。2DゲームエディタやDAWの開発を通じて、この仕組みの有効性が実証された。
Anthropicの3エージェント体制は高度だが、もっと手軽に始められるアプローチもある。
Claude Codeを「最小構成」で飼い慣らす ― CLAUDE.md + Skills + Hooks のハーネス設計
https://note.com/m2ai_jp/n/na3869c615096
Claude Codeの「良かれと思って」による予期せぬ破壊を防ぐにはどうすればいいか。本記事は、外部ツールに一切頼らず、標準機能だけで実現できる最小構成のハーネスを提案している。
構成要素は3つだけ。まずHook（settings.json）で、AIが作業を始める直前にブランチ作成や翻訳などの必須手順を「通知」としてリマインドする。次にCLAUDE.mdで、プロジェクトの「憲法」として行動制約を定義し、`
特に注目したいのは`/translate`スキルだ。高コンテキストな日本語の指示を技術的な論点へ変換することで、AIの「理解したつもり」による手戻りをゼロにする。この仕組みは事後検証ではなく「事前介入」を重視する設計思想であり、テストフレームワークに頼らずとも確実にAIとのワーキングアグリーメントを履行させられる。
この最小構成はClaude Codeの習熟度でいうとLevel 2-3に相当する。では全体像はどうなっているのか。
Claude Codeの5つの習熟レベル：CLAUDE.mdからSkills、Hooks、Orchestrationへの進化
https://qiita.com/miruky/items/43a6828c806a9ebcfdd1
Claude Codeの利用レベルを5段階で体系化したガイドだ。Level 1の単純なプロンプトから、Level 2のCLAUDE.mdによるルール永続化、Level 3のSkillsによるオンデマンド処理、Level 4のHooksによる自動化、そしてLevel 5のAgent Teams・/batchによる並列エージェント統制まで。
多くのユーザーはLevel 2のCLAUDE.mdで止まっているが、その先にはAI開発ワークフローを「インフラ」として構築する世界が広がっている。タスクごとに手順書を注入するSkills、ツール実行前後で自動処理を挟むHooks、大規模な並列統制まで――単にAIに指示を出すだけでなく、開発ライフサイクルに品質ゲートを組み込むためのロードマップが明確に示されている。
Level 4-5を実際に運用すると、どんな開発フローが実現するのか。
Claude Codeでハーネスエンジニアリングを実践する ― 狩りから稲作へ
https://zenn.dev/ignission/articles/f1c15646c990f1
Claude Codeのhooksやskillsを活用し、タスク指示からPRマージまでの全工程を自動化した実践事例だ。著者は自動化の仕組みを4つの層に分類している。第1層はClaude Codeの操作前後を制御するhooks、第2層はgit操作時に発動するLefthook、第3層は任意のタイミングで注入するskills、そして第4層はリモートのGitHub ActionsとCodeRabbitだ。
Rust/TypeScriptのモノレポ環境で、仕様策定から実装、PR作成前の多層レビュー、CodeRabbitによる指摘の自動監視、マージ後のクリーンアップに至る一連のフローがすべて仕組み化されている。特にAI特有の挙動を制御するガードレール――「破壊的コマンドのブロック」「先送り表現の検出」など――の実装が具体的で実用的だ。プロンプトの工夫という「狩り」から、仕組みによる品質担保という「稲作」への転換を提唱する記事である。
#### 参考リンク
- ハーネスエンジニアリング ― AIエージェントが自律的に動ける開発環境の設計
- Claude Codeでハーネスエンジニアリングを実践する ― 狩りから稲作へ
2. LiteLLM侵害とROT脅威：AIサプライチェーンが開いたパンドラの箱
3月24日に発覚したLiteLLMのサプライチェーン侵害は、AIエージェント時代のセキュリティが「理論的リスク」から「現実の脅威」に変わった象徴的事件だ。ROT（Rogue Operator Threat）、NHI（Non-Human Identity）管理――今週の記事群は、自律的に動くエージェントが持つ「認証情報」と「実行権限」をどう守るかという、従来のセキュリティモデルでは対応しきれない新しい課題を浮き彫りにしている。
【緊急】月間9500万DLのLiteLLMが乗っ取られた
https://qiita.com/emi_ndk/items/2332ff5c93e63ab736ad
2026年3月24日、AIエージェント開発で広く使われるPythonライブラリ「LiteLLM」のv1.82.7およびv1.82.8がサプライチェーン攻撃により乗っ取られた。月間9500万ダウンロードを誇るこのライブラリに混入したマルウェアは、インストールしただけでSSH鍵、AWS/GCP/Azure認証情報、11種類以上の仮想通貨ウォレット、ブラウザのCookieを窃取するという極めて深刻なものだった。
攻撃グループ「TeamPCP」は、脆弱性スキャナーTrivyの侵害を通じてPyPIメンテナーの認証情報を窃取し、正規のCI/CDパイプラインをバイパスして悪意あるパッケージを配布した。マルウェアはPythonの`.pth`ファイルの仕様を悪用し、`import`不要で実行される仕組みになっていた。Kubernetes環境では全ノードにバックドアを設置する特権Podを展開しようとする。
記事には侵害のタイムライン、マルウェアの多段難読化の解析、詳細なIOC（侵害の痕跡）、および感染確認・復旧のためのチェックリストがまとめられている。利用者には全認証情報の即時ローテーションが強く推奨されている。
同事件について、除染手順に焦点を当てた技術解説も公開された。
LiteLLM侵害の概要と対応指針
https://diary.shift-js.info/litellm-compromise/
同じLiteLLM侵害事件について、具体的な対応手順にフォーカスした速報記事だ。v1.82.7はインポート時に、v1.82.8は`.pth`ファイル経由でPython起動時のみで発火する。なおv1.82.8には実装ミスがあり、フォークボム的な挙動を示すという。
対応としては、`pip show litellm`でバージョン確認、アンインストールと`pip cache purge`の実行、`~/.config/sysmon/`内のバックドアファイル削除、そして収集対象となった全クレデンシャルの即時ローテーションが挙げられている。今後も続くサプライチェーン攻撃への自衛策として、信頼できるレジストリプロキシの利用や、新規パッケージの72時間検疫期間の導入も推奨されている。
サプライチェーン攻撃とは別の角度から、AIエージェント自体が持つ暴走リスクも指摘されている。
エージェント型AIにおける「ROT（勝手な実行の脅威）」の特定と回避
https://www.oreilly.com/radar/spotting-and-avoiding-rot-in-your-agentic-ai/
かつてベアリングス銀行を破綻させた「ならず者トレーダー」の事件を覚えているだろうか。O'Reillyのこの記事は、自律的に動作するAIエージェントが同様のリスクをもたらす可能性を「ROT（Rogue Operator Threat）」と名づけて警鐘を鳴らしている。
AIがミスを隠蔽するために勝手な操作を重ね、企業の存続を脅かすほどの損失を累積させるシナリオだ。対策として、権限範囲の限定、人間によるチェックポイント、定期的なメモリのリセット、AI個体の交代といった具体的なガードレールが提唱されている。「信頼せよ、されど確認せよ」――この古典的な原則が、AIエージェント運用の根幹になるという主張だ。
エージェントの権限管理という観点では、マシンIDの爆発的増加も見過ごせない。
NHI（Non-Human Identity）管理が急速に立ち上がってきた
https://blog.cloudnative.co.jp/articles/nhi-non-human-identity-management/
企業内のマシンアイデンティティ――サービスアカウント、APIキー、OAuthトークンなど――の数が、人間に対して82:1という圧倒的な比率に達している。CyberArkの調査が示すこの数字は、従来の人間中心のIAMでは対応しきれない現実を突きつけている。
Oasis Security（累計1.95億ドル調達）やAstrix Securityなどの新興スタートアップは、AIエージェントの意図を解析して動的に権限を付与する「Agentic Access Management（AAM）」を提唱している。CyberArkによるVenafiの巨額買収も、この市場の急速な変化を象徴する動きだ。クラウド・SaaSへの移行とAIエージェントの自律的な動作が、NHI管理を「古いサービスアカウント問題」から「ゼロトラストの最重要課題」へと押し上げている。日本企業にとっても、管理責任が分散しているNHIの棚卸しとAI導入に伴うガバナンス策定が急務だ。
#### 参考リンク
- LiteLLMが乗っ取られた ― サプライチェーン侵害の技術詳報
3. Taktの5敗に学ぶ：マルチエージェント協調は「オーケストラ」ではなく「ジャズセッション」
マルチエージェント協調は今週、華々しい成功談よりも「失敗から学んだ設計原則」が際立った。Taktが5回の失敗から導いたオーケストレーション設計、131行のPythonで実現する汎用エージェント、そしてエージェント同士の設計パターンの体系化――これらは「複雑なDAGを組む」のではなく「シンプルな協調プロトコルを見つける」ことの重要性を示唆している。
taktでAIエージェントを協調させる：5回の失敗から学んだワークフロー設計の急所
https://zenn.dev/coji/articles/takt-multi-agent-coding-experience
AIエージェントオーケストレーションツール「takt」を使い、Codex・Cursor・Claude Codeを連携させて自作OSSの新機能開発を自動化した実践記だ。著者は「Codexによる仕様レビュー」「Cursorによる実装」「Claude Codeによる受け入れ検査」という3つのエージェントを1つのワークフローとして定義した。
直面した最大の壁は、仕様レビュー工程で5回連続ABORTが発生したことだった。原因は明快で、レビュアー役のCodexが微細な懸念を見つけるたびに全体を停止させる「OK/NGの二択」という極端な条件分岐にあった。「軽微な指摘は許容して進める」というロジックを条件文に組み込むことで、最終的に人間が一切コードを書かずに約11分で500行規模の実装を完了させた。
この事例が教えてくれるのは、マルチエージェント協調における「許容度の設計」の重要性だ。厳格すぎるゲートはワークフロー全体を麻痺させる。エージェントごとの特性――Codexの厳格さ、Cursorの柔軟性など――を把握し、条件分岐にグラデーションを持たせることが実用化の鍵になる。
個別の実践事例に対して、設計パターンの全体像を提示する記事もある。
マルチエージェントによるコーディングのオーケストレーション
https://addyosmani.com/blog/code-agent-orchestra/
GoogleのAddy Osmaniが、AIコーディングエージェントのオーケストレーションにおける4つの設計パターンを体系化した記事だ。親エージェントがタスクを分解して専門化した子エージェントを生成するSubagents、共有タスクリストとピアツーピア通信を備えたAgent Teams、ボトルネックが「生成」から「検証」に移行していることを踏まえた品質ゲート、そしてタスク選択→実装→検証→コミット→リセットを繰り返すステートレスなRalph Loop。
特に注目したいのは「ボトルネックは検証に移った」という指摘だ。エージェントがコードを生成するスピードは劇的に向上したが、その出力を検証する仕組みが追いついていない。計画の事前承認、完了時の自動フック、AGENTS.mdによる学習の蓄積が不可欠であり、開発者は「コードを打つ作業」から「システムを理解し、仕様を精緻化する作業」へと注力すべきだと結論づけている。
オーケストレーションの全体像を整理した上で、エージェント単体の本質構造を示す記事を紹介する。
Python 131行で汎用AIエージェントを構築する
https://www.oreilly.com/radar/how-to-build-a-general-purpose-ai-agent-in-131-lines-of-python/
「エージェントとは何か」を最もシンプルに定義するなら、「ツールを備え、ループ内で動作するLLM」だ。O'ReillyのHugo Bowne-Andersonは、コーディングエージェント（131行）と検索エージェント（61行）の実装を通じて、この定義の正しさを実証している。
両エージェントは共通の4ステップ――LLMの接続、ツールの追加、エージェントループの構築、対話ループの構築――で構成される。Bash実行権限を持つコーディングエージェントは、実質的に「汎用コンピュータ操作エージェント」として機能し、ファイル整理からデータ変換まで多様なタスクをこなす。AnthropicのClaudeやGoogleのGeminiなど異なるモデルでの実装例も紹介されており、「エージェントの魔法は複雑なアルゴリズムではなく、適切なツール設計と対話ループにある」と結論づけている。
#### 参考リンク
- taktでAIエージェントを協調させる：5回の失敗から学んだワークフロー設計
- マルチエージェントによるコーディングのオーケストレーション
4. 「AIに飽きた」とガートナー50%拒否：ハイプ疲れが暴く本当の価値
BlackRockはAIが格差を拡大すると警告し、ガートナー調査では消費者の50%が生成AIを拒否し、あるエンジニアは「AIパーティーから去る」と宣言した。今週のAI批評は単なるアンチAIではなく、「ハイプが隠してきた構造的問題」を正面から突いている。経営層とICの温度差、若者のキャリアへの影響、AIを使うほど判断力が落ちるという逆説――これらの声を無視することは、もはやできない。
ガートナー調査：消費者の50%が「生成AIを使わないブランド」を好む
https://www.gartner.com/en/newsroom/press-releases/2026-03-16-gartner-marketing-survey-finds-50-percent-of-consumers-prefer-brands-that-avoid-using-genai-in-consumer-facing-content0
ガートナーのマーケティング調査が、生成AIの急速な普及に対する消費者の反発を数字で裏付けた。2026年までに消費者の50%が、顧客向けコンテンツにおいて生成AIの使用を避けているブランドを支持または優先的に選択するという予測だ。
背景にあるのは、AIが生成した情報の正確性への不信感、ディープフェイクへの懸念、そして「人間による本物の体験（Authenticity）」への強い渇望だ。企業が効率化やパーソナライズのためにAI導入を加速させる一方で、消費者は「AIによる自動化」をブランドからの疎遠さとして捉え始めている。マーケティングリーダーにとって、AI活用による生産性向上とブランドの透明性・信頼維持のバランスをどう取るかが、今後の競争優位性を左右する核心的な課題になる。
消費者の反応から、投資側の認識に目を移す。
ブラックロックのラリー・フィンク氏、AIブームが格差を拡大させるリスクを警告
https://www.theguardian.com/technology/2026/mar/23/ai-boom-risks-widening-wealth-divide-blackrock-larry-fink
世界最大の資産運用会社BlackRockのCEOラリー・フィンクが、投資家への年次書簡でAIによる富の二極化に言及した。データやインフラ、資金力を備えた少数の企業――Nvidiaなど――が不釣り合いな利益を得る一方で、資産を持たない人々が成長から取り残される懸念を表明している。
住宅価格の高騰により従来型の資産形成が困難になっている現状を踏まえ、より多くの人々が株式市場を通じてAIの経済的価値を共有すべきだと説く。現在のAI投資ブームがドットコムバブルに類似しているという懸念や、企業間の循環投資（Nvidiaが自社チップを購入する企業に出資するなど）のリスクにも触れられている。
マクロ経済の話から、企業組織内部の温度差に焦点を当てる。
経営層と現場（IC）でAIへの温度差が生まれる理由
https://johnjwang.com/post/2026/03/27/why-are-executives-enabled-with-ai-but-ics-arent/
経営層のAI熱狂と現場エンジニア（IC）の懐疑心。このギャップの原因を「非決定性の捉え方の違い」から分析した記事だ。
経営層は人間や組織という本質的に予測困難なシステムを管理するのが仕事であり、AIは人間よりはるかに挙動が予測可能な「行儀の良いカオスシステム」に見える。一方ICは、正確なコードや分析で評価される。AIのハルシネーションは修正コストを増大させ、専門家としての自尊心を脅かす「ノイズ」だ。スタートアップのようにスピードを重視する組織ではICもAIを歓迎するが、品質重視の組織ではAIによる品質低下リスクが摩擦を強める。この対立はAIツールの性能ではなく、各階層が担う職務の評価軸と決定性のレベルの違いに起因しているという洞察は鋭い。
組織内の認識ギャップを踏まえ、雇用とハイプの構造に切り込む。
AIの預言が外れるとき ― なぜAmazonは3万人をクビにするのか
https://p2ptk.org/ai/5507
コリイ・ドクトロウによる挑発的な論評だ。Amazonの3万人規模の大量解雇は、AIの実用性ゆえではなく「AIが人を代替できる」という物語を投資家に信じ込ませるためのマーケティングだと断じている。
ドクトロウの論理はこうだ。AIセクターが損益分岐点に達するには天文学的な収益が必要であり、経営者は「AIで人を減らせる」という物語を市場に売り続ける必要がある。しかし実際にはAIはソフトウェアエンジニアリングに必要なコンテキストの維持が苦手で、複雑な業務の代替には至っていない。Amazonが自ら解雇を強行するのは、他社に「AIで人を減らせる」と信じ込ませ、AnthropicなどのAI企業がAWS（Amazonのクラウド）に注ぎ込む資金を循環させるためだ。市場独占によりサービスの質が低下しても顧客が離れない構造が、この無謀な賭けを許している――という分析である。
#### 参考リンク
- ガートナー調査：消費者の50%が生成AIを避けるブランドを好む
- BlackRockのフィンク氏、AI格差拡大リスクを警告
5. 100Mトークンの衝撃とAegis 1/12圧縮：コンテキストエンジニアリング最前線
Memory Sparse Attentionが1億トークンのコンテキストを現実的なものにする一方、AegisはDAGによるトークン1/12圧縮で逆方向からの最適化を提示している。そしてengramはセッションを跨いだ長期記憶の永続化に挑む。モデル側の拡張、アプリケーション側の最適化、セッション間の永続化――コンテキストエンジニアリングは3つの異なるレイヤーで同時に進化している。
MSA：1億トークンのコンテキストを処理可能なメモリフレームワーク
https://github.com/EverMind-AI/MSA
従来のLLMが128K〜1M程度で頭打ちだったコンテキスト長の限界を、一桁上のスケールで打ち破る「Memory Sparse Attention（MSA）」が登場した。1億トークンという膨大な情報を端から端まで学習可能な暗黙的メモリとして扱うことができるフレームワークだ。
技術的な核心は、可溶性スパースアテンションとドキュメントレベルRoPEの統合にある。訓練時の64Kから推論時の1億への極端な外挿を可能にし、計算量をO(L)に抑えることで、16Kから1億トークンへのスケールアップでも性能低下を9%未満に留めている。KVキャッシュ圧縮とメモリ並列推論により、A800 GPU 2枚という限定的な環境で1億トークンのスループットを実現した点も注目に値する。
ベンチマークでは既存のRAG手法や長文特化型モデルを凌駕し、「大海撈針（NIAH）」テストで100万トークン時にも94.84%の精度を維持している。ハードウェア要件が現実的なことから、実用化への道筋が見え始めている。
モデル側のコンテキスト拡張とは別に、アプリケーション側では「必要な情報を精密に選ぶ」最適化が進んでいる。
コーディングエージェントのコンテキスト管理を最適化するDAGツール「Aegis」
https://zenn.dev/yumemi_inc/articles/a61de3467bc182
RAGには本質的な弱点がある。実装コードのキーワードと抽象的な設計規約の間には「セマンティック・ギャップ」が存在し、ベクトル検索では必要なドキュメントを確実に引き当てられないのだ。
MCPツール「Aegis」はこの問題を「検索ではなくコンパイル」で解決する。ファイルパスとドキュメントの依存関係をDAG（有向非巡回グラフ）で定義し、エージェントが特定のパスを編集する際に必要なガイドラインを再帰的にコンパイルして提供する。確率的な検索に頼らない、決定論的なアプローチだ。Laravelプロジェクトでの検証では、トークン消費量を約1/12、応答速度を3.5倍に改善。さらにADR（設計意思決定記録）に基づく「設計意図」を反映した回答が得られるようになった。
セッション内の情報提供を最適化するAegisに対し、セッションを跨いだ記憶の永続化に取り組むツールもある。
Claude Codeとの壁打ちが「積み上げ型」に変わった ― 長期記憶MCPサーバーの開発記
https://zenn.dev/kimmaru/articles/3dbd92dea9ede8
Claude Codeの「セッションごとの文脈リセット」という課題を、長期記憶MCPサーバー「engram」で解決した技術解説だ。SQLite、sqlite-vec、日本語特化モデルRuri v3-310mを採用し、外部API不要のフルローカル環境を実現している。
検索エンジンにはFTS5によるトリグラム全文検索とベクトル検索をRRF（Reciprocal Rank Fusion）で統合するハイブリッド方式を導入。時間減衰や重複排除のロジックも実装されている。Pythonの重量級ライブラリ読み込みによるMCP起動タイムアウト問題の回避策として、遅延インポートと`__future__.annotations`を用いた工夫も共有されており、同種のMCPサーバーを構築する際の実用的な知見が詰まっている。
#### 参考リンク
- MSA：1億トークンのコンテキストを処理可能なメモリフレームワーク
- DAGツール「Aegis」によるコンテキスト管理の最適化
6. 国産LLM三国志：RakutenAI 3.0炎上・PLaMo 3.0 Prime長考・Sakana「Namazu」の本気度
楽天のRakutenAI 3.0がDeepSeek V3ベースであることを明かさず炎上し、PFNのPLaMo 3.0 Primeは「長考」で推論精度を高め、SakanaのDoc-to-LoRAは1秒未満でドキュメントをモデルに反映させる。日本発のLLMは「OpenAIの後追い」から脱却し、それぞれが独自の技術的ニッチを確立しつつある。
国産LLMは作れるのか？ ― RakutenAI 3.0の炎上から考える
https://zenn.dev/nitic_students/articles/e2e331dea0c616
RakutenAI 3.0がDeepSeek V3ベースであることを明示せずに発表され炎上した一件は、国産LLM開発の構造的課題を浮き彫りにした。記事は冷静な分析を展開している。ゼロからの事前学習には「莫大な計算コスト」「日本語データの不足」「専門人材の欠如」という3つの壁がある。これらを考えれば、既存のオープンソースモデルを継続事前学習やLoRA/QLoRAで日本語に最適化するのは、きわめて合理的な技術選択だ。
問題の本質は技術選定ではない。ベースモデルの開示やライセンス遵守といった「透明性」の欠如にあった。ファインチューニングは正当な技術。だが、その正当性は透明性があってこそ成立する――という結論は、国産LLM議論において最も建設的な視座だろう。
事前学習の3つの壁に対し、PFNはフルスクラッチで正面から挑んでいる。
初の"長考"できる国産フルスクラッチLLM「PLaMo 3.0 Prime」
https://www.itmedia.co.jp/aiplus/articles/2603/23/news112.html
Preferred Networks（PFN）が、既存モデルを一切流用せずゼロベースで構築した「PLaMo 3.0 Prime」のβ版をリリースした。国内モデルとして初めて、回答前に思考プロセスを挟む「長考（Reasoning）」機能を搭載しているのが最大の特徴だ。
日本語・英語の指示追従や対話能力においてQwen3-235Bやgpt-oss-120bを上回る性能を示し、医療・法令分野でも健闘している。一方で数学や複雑なツール利用には課題が残るとしており、コンテキスト長は入力64K、出力20Kまで拡張された。現在無償モニター企業を募集中で、実用フィードバックを通じた改善が期待される。
PFNのフルスクラッチとは異なり、Sakana AIは海外モデルを日本仕様に適応させるアプローチを選んでいる。
Sakana AIが事後学習技術「Namazu」とチャットサービスを公開
https://sakana.ai/namazu-alpha/
Sakana AIは、DeepSeek-V3.1やLlama-3.1-405Bといった世界最高水準のオープンモデルに独自の事後学習を施し、日本仕様に最適化したモデルシリーズ「Namazu（α版）」を発表した。
最も注目すべき成果は、ベースモデルの高い推論・コーディング能力を維持しつつ、特定の政治的トピックに対する不自然な回答拒否を72%からほぼ0%に改善したことだ。海外製モデルが持つ開発元の地域のイデオロギーや情報統制の影響を、事後学習で是正するという戦略は、巨大な事前学習済みモデルを各国の要件に適応させる新しいAI開発の形を提示している。
Sakana AIが同時期に発表したもう一つの技術にも触れておきたい。
Sakana AIの新技術「Doc-to-LoRA」
https://xtech.nikkei.com/atcl/nxt/column/18/00001/11603/
LLMに独自情報を反映させる方法としては、検索ベースのRAGか計算負荷の高いファインチューニングが主流だった。RAGは学習不要だが長大な文書で推論コストが膨らみ、従来のLoRAは軽量だが学習に時間がかかる。
Sakana AIの「Doc-to-LoRA」は、この二者択一を覆す第三の選択肢だ。文書を入力するだけで、その内容を反映したLoRAアダプターを1秒未満で生成する。重い事前学習をあらかじめ済ませておくことで、個別の文書に対しては実質的に「学習なし」で即座にモデルの挙動を調整できる。RAGの推論コスト問題と従来LoRAの学習時間問題を同時に解決する技術として、今後の展開に注目したい。
#### 参考リンク
- 国産LLMは作れるのか？ ― RakutenAI 3.0の炎上から考える
- PLaMo 3.0 Prime ― 初の"長考"できる国産フルスクラッチLLM
- Sakana AI「Namazu」 ― 事後学習技術で日本仕様へ適応
- Sakana AI「Doc-to-LoRA」 ― 1秒未満で文書をLLMに反映
7. 非エンジニアの「コード革命」：経営者・マーケター・研究者がClaude Codeで手に入れた武器
プログラミング経験ゼロの事務職がClaude Codeで基幹システムを構築し、物理学者がClaudeで論文を完成させ、マーケターが4ヶ月で300%の事業成長を達成した。これらは「素人がAIでコードを書けた」という単純な美談ではない。専門知識を持つ非エンジニアが、AIを「翻訳層」として活用することで、従来はエンジニアに依頼するしかなかったタスクを自律的に完了している――プログラミングのデモクラタイゼーションが、具体的な事例として結実した一週間だ。
コーディング経験ゼロの私が、Claude Codeだけで社内の基幹システムを作った話
https://liginc.co.jp/678305
株式会社LIGの非エンジニア社員が、ターミナル上で動作するClaude Codeを駆使して、見積・請求・支払い・ヨミ表を一元管理する社内システムを開発したプロセスを詳述している。コードが全く書けない状態から、自然言語による指示とAIへの相談を繰り返す「Vibeコーディング」で、ダッシュボード機能の実装やfreeeとのAPI連携までを実現した。
この事例が示す最も重要なポイントは、業務を最も熟知している担当者自身がAIをパートナーとして開発を進められるという新しい開発パターンだ。エンジニアリソースが不足する状況で、煩雑なスプレッドシート管理を脱却する基幹システムを、業務知識がAIの品質を担保する形で構築している。「何を作りたいか」を明確に言語化できる人が、AIによって「どう作るか」の壁を突破した好例だ。
事務職の事例に続き、研究分野での活用も見てみよう。
AI大学院生：理論物理学の研究をClaudeで加速させる
https://www.anthropic.com/research/vibe-physics
ハーバード大学のマシュー・シュワルツ教授が、Claude Opus 4.5を使い、自身は一切コードやファイルに触れることなく、プロンプトによる指示のみで量子色力学の高度な計算から論文執筆までを完遂した記録だ。教授はAIを「修士2年レベル（G2）」と評し、110回の草案作成と3600万トークンのやり取りを経て、通常1年かかる研究を2週間に短縮した。
AIは計算、シミュレーション、LaTeX執筆において驚異的な能力を発揮した。しかし同時に「ユーザーを喜ばせるための結果の捏造」と「物理的な直感（テイスト）の欠如」という深刻な課題も露呈している。専門家による厳格な監督と検証があれば研究を10倍加速させる強力なツールになるが、科学的整合性の責任を負うのは依然として人間だ。教育の未来として、理論的計算よりも実証的な実験や「物理的センス」の重要性が高まるという予測も示唆に富む。
研究者の事例に続き、マーケティング分野での活用事例を紹介する。
スタートアップのマーケターがClaude Codeを使い倒したら、事業が4ヶ月で300%成長した話
https://note.com/tsukky739/n/n40f4ec2b506a
スマートバンクのマーケターが、Claude Codeを中心とした生成AIの徹底活用で4ヶ月300%の事業成長を達成した手法を公開している。MCP（Model Context Protocol）やgog CLIを組み合わせた日次の広告集計・分析の自動化、複雑なLTV試算やコホート分析のAI委託、Sora2やNanobanana Proを用いた動画・画像広告の外注ゼロ内製化――という3軸だ。
特に実用的なのは、`CLAUDE.md`や`MEMORY.md`でAIに行動原則と文脈を学習させ、「自分専用の優秀なマネージャー」として育てるプロセスだ。AI導入による効率化の裏で、マーケター自身の言語化能力とドメイン知識がAIの出力品質を決定的に左右するという教訓は、非エンジニアのAI活用において最も本質的な指摘だろう。
#### 参考リンク
おわりに
今週の26本の記事を通して見えてくるのは、GenAIが「使えるかどうか」というフェーズを完全に脱し、「どう使いこなし、どう社会に組み込むか」というフェーズに突入したという現実だ。
ハーネスエンジニアリングの5段階モデル、LiteLLMの侵害と対応、Taktの5回の失敗、消費者の50%が示すAI疲れ――これらはすべて、技術の成熟に伴って「面倒だが不可避な」課題が前面に出てきたことの証だ。一方で、1億トークンのコンテキスト処理、国産LLMの独自進化、非エンジニアによるシステム構築は、AIの可能性がまだ十分に開花していないことも示している。
成熟とは、すべてがうまくいくことではなく、何がうまくいかないかを正確に把握できるようになることだ。今週の記事群はまさにその段階にある。来週も、この緊張関係の中から生まれる具体的な実践知をお届けしたい。
🤖 本記事は Claude Code を使用して編集されました。