おはようございます、マイクです。
時刻は朝7時、今日は2026年3月29日、日曜日ですね。
ここからの時間は「zenncast」、Zennで今日トレンドの記事を、ゆるっと、でも中身はしっかりめにご紹介していきます。コーヒー飲みながら、のんびりお付き合いください。
今日はですね、全部で5本の記事を紹介していきます。技術寄りなんですが、AI好きな方、セキュリティ気になる方、ドキュメント整えたい方まで、幅広く刺さりそうなラインナップになってます。
まず1本目。
タイトルは「Claude Code同士が会話できるようになったらしいので試してみた」。
これ、ちょっとワクワクするやつです。同じPCの中で、複数のClaude Codeが、お互いを見つけてメッセージを送り合えるようになる、っていう仕組みを試してみた記事ですね。
キモになっているのが「claude-peers-mcp」というMCPサーバー。これをWindows環境でどうセットアップするか、かなり実務目線で丁寧に書かれています。条件としては、Windows10/11で、Claude Codeのバージョンは2.1.80以上、claude.aiにログイン済み、さらにGitも入っていること。
手順としては、まずBunをインストールして、リポジトリをgit cloneして、bun install。それからBunのフルパスをちゃんと確認しておく。ここまでは王道なんですけど、面白いのは「READMEの通りにやるとMCP登録で失敗するよ」という実体験が共有されているところなんですよね。
そこで登場するのが、ホームディレクトリにある .claude.json。ここのmcpServersっていう設定に、cmd経由で bun server.ts を叩く形で書き込んであげるのがコツ。これで claude mcp list を叩いたときに、無事「Connected」って出れば成功、というわけです。
動かし方もちゃんと書いてあって、ターミナルを2つ開いて、どっちも claude --dangerously-load-development-channels server:claude-peers を実行。それぞれのセッションで list_peers を実行して、相互に見えてるか確認する。さらに set_summary で名前をつけてあげると、「この子はAくん、この子はBさん」みたいに識別できる。で、send_message で名前やpeer IDを指定してメッセージ送信、必要なら check_messages で手動で受信確認、という流れです。
要するに、「複数エージェントが同じマシンで対話しながらタスクをこなす」ための、かなり実践的なセットアップガイドになっていて、「こういうのやってみたいけど環境構築が怖い」という人には、いい踏み台になりそうだなと感じました。エージェント同士が本当に喋り始めると、一気にSF感増しますよね。
。 。 。 。
続いて2本目。
タイトルは「国産LLMは作れるのか？ - RakutenAI 3.0の炎上から考える」。
これは、最近話題になったRakuten AI 3.0の騒動を入り口に、「日本で本当にフルスクラッチのLLMって作れるの？」という根本的な問いに向き合った記事です。
楽天は「国内最大規模」「GPT-4o超え」と大々的に打ち出したんですが、モデルの設定ファイルを見てみると、実はDeepSeek V3をベースにしたMoEモデルだった、というのが判明。ここで問題になったのが、「何をベースにしているか」「それに対して何をしたのか」が、当初ほとんど説明されていなかった点なんですね。MITライセンス表記も不足していて、「技術選択そのもの」よりも「透明性のなさ」が炎上の本質だった、という整理がされています。
じゃあ、「純国産の巨大LLMを、日本企業がゼロから作る」のは現実的なのかというと、計算資源、日本語データの量、そしてそれを回せる人材、この3つの制約から、かなり厳しいのが現状だと指摘しています。実際、多くのプレイヤーはLlamaやQwen、DeepSeekといった既存のオープンモデルをベースにしている。
そのうえで、「現実的な強みの出し方」として挙げられているのが、既存モデルへの継続的な事前学習、日本語に特化したLoRA/QLoRA、ドメイン特化の高品質データや合成データ、そして軽量モデルとクラウドを組み合わせたコスト効率の良い構成、といったものです。
印象的なのは、「国産かどうか」よりも、「何をどう組み合わせ、どう説明するか」がユーザーからの信頼を左右する、というメッセージです。AIを使う側にとっては、スペックの数字より、その裏で何が起きているのか知れるかどうかが、安心感に直結しますよね。
。 。 。 。
3本目。
タイトルは「コーディングエージェントのサンドボックス技術を理解する」。
これは、Claude Codeみたいなコーディングエージェントが、どこまで何にアクセスできるのか、そしてそれをどう安全に制御するのか、というセキュリティのど真ん中の話です。
エージェントって、プロジェクト内のファイルだけじゃなくて、環境変数、ホームディレクトリ配下の ~/.ssh や ~/.aws みたいな、めちゃくちゃ機密性の高い情報にも、原理的にはアクセスできてしまいます。ここにプロンプトインジェクションなんかが絡むと、うっかり情報が外に出てしまうリスクが跳ね上がる。
記事では、単に .gitignore とかアプリケーション側の制御に頼るのは危険で、OWASPも「権限悪用」や「サプライチェーン汚染」対策としてサンドボックスを推奨している、と説明しています。そこからサンドボックス技術を3層構造で整理してくれているのがポイント。
1つ目がOSネイティブな仕組み。macOSのSeatbeltとか、LinuxのLandlockとseccompの組み合わせ、それからbubblewrapみたいなやつですね。高速で軽いけど、ホストのカーネルを共有しているので、カーネルに穴があると影響を受ける、という限界があります。
2つ目がコンテナ。DockerやgVisorなど、「ちょっと強めの隔離」をしてくれるもの。ただ、これも基本的にはカーネル共有なので、脆弱性次第ではエスケープされる可能性がゼロではない。
3つ目がMicroVM。AppleのVirtualization Frameworkとか、Docker Sandboxのような、独立したカーネルを持つ小さな仮想マシンです。これによって攻撃面をグッと減らせる。Claude CodeやClaude Desktop、Codexなどが、実際にどのレイヤーを採用しているかにも触れていて、「あ、裏側ってこう動いてるんだ」とイメージしやすくなっています。
最終的な結論としては、「どこまで守りたいか」「カーネルのゼロデイまで気にするか」によって技術選択は変わるけれど、結局一番効くのは、エージェントが触れるリソースを徹底的に絞る“最小権限の原則”だ、という話で締められています。便利さと怖さが両立する世界だからこそ、こういう整理はありがたいですね。
。 。 。 。
4本目。
タイトルは「Docling で PDF を Markdown に変換してみる」。
AIを本番投入している人なら、「PDFからテキスト抜いただけだと、ぜんぜん精度出ないんだよな……」って、一度は思ったことあると思うんですけど、その「なんでそうなるのか」に真っ向から向き合った記事です。
単純にテキストだけを抜き出すと、レイアウトや見出し、表の構造なんかが全部バラバラになってしまって、LLMが文書の意味や流れを追いにくくなる。それを解決しよう、ということで紹介されているのが、IBM Research Zurich発のオープンソースライブラリ「Docling」。
Doclingは、入力された文書を、StandardPdfPipelineとかSimplePipelineといったパイプラインで処理して、最終的に DoclingDocument という共通形式に変換します。で、そこからMarkdownやJSON、HTMLなどへ出力できる。大事なのは、見出しや段落、表などの“構造”をできるだけ保ったまま出せるところなんですよね。
使い方もシンプルで、インストールは pip install docling。コマンドラインでは、docling sample.pdf みたいに叩くとMarkdown化してくれて、--to オプションで JSON や YAML、HTMLにも切り替えられる。--output で一括変換、URLを直接指定して取得、--verboseでログの詳細表示、さらに --ocr-engine でOCRエンジンの切り替えもできる、と。PythonからはDocumentConverterを使って、自分のスクリプトやパイプラインに組み込めます。
実際にarXivのPDFをMarkdownにしてみた例も紹介されていて、「完全ではないけど、見出しや段落の構造はかなり保たれている」という所感です。RAG用のデータづくりとか、社内ドキュメントをLLMに食べさせる前処理としては、かなり使えそうだなという印象。
記事のメッセージとしては、「文書整形はLLM精度にめちゃくちゃ効くから、前処理をちゃんとやろう。その選択肢のひとつとしてDoclingは試す価値大きいよ」という感じで、地味だけど超重要な部分を押さえてくれている内容でした。
。 。 。 。
そして最後、5本目。
タイトルは「サプライチェーン攻撃対策の社内展開したやつの抜粋(SHA pinning必須化/min-release-age/Takumi Guard)」。
これはprimeNumber社が、最近相次いだTrivyやLiteLLMの侵害を受けて、「うちはこう対策してます」というのを具体的に共有してくれている記事です。守りの話なんですけど、かなり実務寄りで参考になります。
紹介されている対策は3つ。まず1つ目が、GitHub Actionsにおける外部Actionの「SHA pinning必須化」。つまり、タグだけ指定するんじゃなくて、コミットハッシュでバージョンを固定する、というルールです。これを徹底することで、後からタグを書き換えられて、意図しないコードが混ざるのを防ぐことができます。しかも、自分が直接書いているActionだけじゃなくて、そこから呼び出される依存Actionも対象にしているのがポイント。
そのチェックのために、「check-actions-sha-pinning」という独自スクリプトを用意して、ワークフローと依存関係のSHA pinning状況を一括で確認できるようにしているそうです。未対応のところは、更新するか、代替のActionを探すか、PRを送るか、最悪廃止するか、という判断を促す仕組みになっている。
2つ目が、npmやpnpm、uv、Dependabot、Renovateといったパッケージ管理・更新ツールに対して、「min-release-age」とか「cooldown」「minimumReleaseAge」といった設定を入れて、新しく公開されたパッケージは、数日間はインストールできないようにする、というもの。要するに、「公開されたばかりの怪しいバージョンを、即座にプロダクションに取り込まない」ための検疫期間ですね。
3つ目が、GMOグループのFlatt Securityが提供している無償ツール「Takumi Guard」を使った追加防御。npmとPyPIに対して、もう一段フィルタリングをかけるイメージです。ただ、無償サービスなので継続性や責任範囲には注意が必要だよね、という冷静な視点もあって、自社でもこのTakumiを利用していることから、一定の安心感を持ちつつ、案内と試験導入を進めている、と書かれています。
著者も「これで完全防御できるわけじゃないけど、リスク低減効果は高い」と判断して導入していて、こういう取り組みを担うCorporate SREも募集してますよ、という流れで締めくくられています。セキュリティ施策って、どうしても後手になりがちなんですが、「ここまで具体的に社内ルールを言語化してくれている」のは、他社にとってもすごく参考になるなと感じました。
。 。 。 。
そろそろお別れの時間になってきました。
今日は、同じPC上のClaude Code同士を会話させるMCPサーバーのセットアップから、日本のLLM開発と透明性の話、コーディングエージェントのサンドボックス技術、Doclingを使ったPDF→Markdown変換、そしてサプライチェーン攻撃対策の社内展開まで、5本を一気に駆け足でご紹介しました。
気になった記事があれば、詳しい内容はこの番組のショーノートにまとめてありますので、そちらから元記事もチェックしてみてください。
「zenncast」では、番組の感想や、「こんなテーマ扱ってほしい」「この技術どう思う？」といったメッセージもいつでも募集中です。あなたの現場での悩みや、ちょっとした成功体験なんかも、ぜひシェアしてもらえると嬉しいです。
というわけで、今回のお相手はマイクでした。
次回の「zenncast」も、またこの時間にお会いできるのを楽しみにしています。
それでは、今日も良い一日を。いってらっしゃい。