おはようございます。朝のお目覚め、いかがでしょうか。
「zenncast」パーソナリティのマイクです。
今日は2026年3月16日、月曜日の朝7時を少し回ったところからお届けしていきます。
この番組では、Zennに掲載されている記事の中から、いまホットなトレンド記事をピックアップして、朝の支度のおともになるようなお話をしていきます。通勤・通学中のあなたも、在宅ワーク前のコーヒータイムのあなたも、どうぞゆるっとお付き合いください。
さて今日は、Zennで話題になっている記事を、ぜんぶで5本ご紹介していきます。生成AIでのパワポづくりから、Claude Codeの便利機能・ガードレールの話、Simulinkとの連携、そして最後はDockerイメージをファイルレベルで深掘りする、というなかなか技術寄りのラインナップになっています。エンジニアの方はもちろん、「最近のAIまわり、ぜんぜん追えてないんだよね〜」という方にも、ざっくり全体像がつかめるようにお話していきますね。
まず1本目。
タイトルは「生成AIでパワポを作る方法一覧【2026年3月版】」。
これは「AIにスライド作らせたいんだけど、どのサービスを使えば“ちゃんと編集可能なPPTX”ができるの？」という、実務で一番モヤモヤしがちなポイントを、かなり整理してくれている記事です。著者がまず強調しているのが、「PPTX対応」と「編集可能なPPTX」は別物だよ、という話。NotebookLMとか、Marpの標準出力みたいに、スライドを“画像として”パワポに突っ込んじゃうタイプだと、見た目はそれっぽくても、あとから日本語を直したり、レイアウトをちょっと動かしたりするのがほぼ無理なんですよね。Gammaも編集はできるけど、開いてみるとレイアウト崩れが気になったりする。一方で、Claude.aiの「PPTX Skill」は、中でpython-pptxを使ってちゃんとスライド構造を組んでくれるので、テンプレート継承しつつ、あとから手作業で直せる“実務用PPTX”を安定して出してくれるのが推しポイントとして紹介されています。Markdown派には、Marp＋AIでスライドをテキスト管理してGit運用するスタイルも紹介されていて、「最終的に編集可能なPPTXにするには、ちょっと実験的なオプションが必要で制約もあるよ」という注意書き付き。そして、一番制御性が高いのが、PptxGenJS＋Claude Codeみたいな“コード生成型”。slides.yamlにスライドの内容とナレーションを書いておいて、theme.tsやhelpers.tsでデザインルールを分離することで、デザインが一貫したPPTXと、場合によってはナレーション付き動画まで自動生成できる構成が紹介されています。まとめとしては、「単発でちゃちゃっと作るならClaude.ai」「Markdownで管理したいならMarp」「再現性と拡張性をガチで求めるならコード生成型」という、用途別のおすすめがわかりやすく示されていました。会社の定例資料とか、プロダクト紹介スライドを頻繁に作る人には、かなり実務寄りで刺さる内容ですね。
。。.。。.。..
続いて2本目。
タイトルは「課題ベースで学ぶClaude Code便利機能」。
Claude.aiの普通のチャットって、どちらかというと「相談に乗ってくれる賢い先輩」みたいな位置づけですけど、Claude Codeは「リポジトリを直接いじって、テストまで回してくれる作業エージェント」というのが出発点になっています。この記事では、「こういうとき、どうしたらいいの？」という課題ベースで、Claude Codeをどう使いこなすかがQ&A形式でまとまっています。まず、プロジェクト固有のルールは「CLAUDE.md」と「/init」で定義しておいて、ルーティン的な自動処理はHookで仕込む、という設計。「毎回同じこと説明してるな…」を減らすやり方ですね。許可確認がうるさい、という問題にはpermissions設定や通知Hookを使ってバランスを取る話も出てきます。コンテキストが汚れてきたときは、/clear・/compact・rewind・forkといったコマンドで会話を整理し、大きめのタスクはPlanモード＋「Edit automatically」で、まず全体の計画を立ててから、一気に自動実装してもらうスタイルが推奨されています。外部サービス連携はMCPを使い、スコープをきっちり区切ることが重要、というあたりは、セキュリティ意識高めな人にも役立ちそうな内容ですね。さらに、よくやる作業はカスタムコマンドにまとめて、Claude自身に「どのワークフローを使うべきか」選ばせたいときはSkillとProgressive Disclosureで分岐を設計する。難しそうに聞こえますが、Skill-creatorやPluginを使うと、この辺の設定自体もClaudeに手伝ってもらえるよ、というのが心強いポイントです。個人的に面白かったのは、git worktreeと組み合わせて「自分はこのブランチ、Claudeはあっちのブランチ」と並列開発するワークフロー。まずはエージェントに任せてみて、「ここちょっと不満だな」と思うたびに機能追加していこう、という現実的なアドバイスで締めくくられていました。
。。.。。.。..
3本目。
タイトルは「Claude Codeのガードレールには3つのレイヤーがある」。
これはちょっとヒヤッとする実話から始まる記事です。オンラインコミュニティを運営している著者が、Claude Code経由でうっかり `terraform destroy` を実行してしまい、本番RDSを含むインフラを全削除してしまった、という事故。これをきっかけに、「Claude Codeのガードレールって、どこまで本当に効くの？」というのを3つのレイヤーに分けて整理しています。まずLayer1の「CLAUDE.md」。これはLLMへの“お願い”レベルで、あくまでプロンプトなので強制力はなく、「セキュリティ用途には使っちゃダメだよ」と明言されています。次がLayer2、アプリ側のsettings.json。ここはコマンド実行前にアプリがチェックしてくれるので、ある程度は「危ない操作はブロックする」ことができるんですが、問題は「Claude Code自身がこのファイルを書き換えられてしまう」という点。つまり、最終防衛ラインにはならないんですね。そして最も重要なのがLayer3の「managed-settings.json」。これはOSのシステムディレクトリに置く設定で、sudoがないと書き換えられない場所に置く想定。ここにルールを書くことで、アプリからは絶対に変更できない“本物のローカルガードレール”が作れる、という整理です。さらに記事では、「そもそも `gh pr merge` とか、CI/CDを起動しちゃう部分はGitHub側でブランチ保護やEnvironmentsを設定して、サーバーサイドから封じるべきだよね」という話も出てきます。ローカルのガードレールと、GitHubなどリモート側の制約を組み合わせて、多層防御を設計することの大事さを、実際の事故を踏まえて解説してくれている内容でした。Claude Codeを本番環境に接続しようとしているチームは、ぜひ一度読んでおきたい記事ですね。
。。.。。.。..
4本目。
タイトルは「ClaudeCodeでSimulinkを操れるか」。
制御工学とかモデルベース開発の現場でおなじみのSimulink。ブロックを線でつないでいくビジュアルプログラミングなので、「これAIで扱うの、さすがにしんどいでしょ…」と思いがちなんですが、著者は「Simulinkモデルって、実はMATLABコマンドから生成できるよね？」というところに目をつけて、Claude Codeにやらせてみた、というチャレンジ記事です。最初は、正弦波からScopeにつなぐだけのシンプルなモデルをMATLABスクリプトで生成させて、そこは問題なくクリア。そのあと、2次遅れ系の負帰還系モデルを作らせると、最初は配線がぐちゃっとしていたり、未接続の部分が残っていたりしたものの、Claude Codeと対話しながら「ここ線が変だよ」「こことここをつなぎ直して」といった修正を繰り返すことで、最終的にかなりきれいなモデルまで持っていけたそうです。さらにPID制御器を追加して応答を確認していくフェーズでは、別途手動で作ったモデルを読み込ませて、Claude Codeに構造解析をさせたうえで、「To Workspace」ブロックを追加したり、シミュレーションしながらPIDゲインをチューニングさせる、という使い方も試しています。その結果たどりついたのが、P=5、I=4.5、D=5というパラメータ。オーバーシュートと整定時間のバランスがいい「ほどよい応答」が得られた、という話でした。ここまで読んで、「あれ、SimulinkってAI苦手なんじゃなかったの？」という印象から、「モデル構築からパラメータ調整まで、意外と実用レベルで使えるかも」という希望が見えてきます。著者は最後に、「実機とつないで自動でモデルを改良していく」といった応用の可能性にも触れていて、制御系エンジニアにとっては夢が広がる内容でした。
。。.。。.。..
そして5本目。
タイトルは「Dockerイメージを深掘りしてみる」。
これはインフラ・コンテナまわりを触っている人には、かなりツボな記事です。Dockerイメージって、普段は「タグ名でpullして、コンテナ起動するだけ」のブラックボックスになりがちですけど、その正体は「複数レイヤの集合体」で、それぞれが独自のファイルシステムを持つtarアーカイブとして保存されているんですよね。記事ではamazonlinux:2023ベースのシンプルなDockerfileを例にして、`docker image save` でイメージを丸ごと展開し、中身のファイルを一つ一つ見ていきます。登場するのが、manifest.json、index.json、Config、そして各レイヤのtarファイル。manifest.jsonはDocker専用の“設計図”のようなファイルで、どのConfigを使うのか、どのLayers（圧縮レイヤのハッシュ）を積み上げるのか、RepoTagsは何か、といった情報が入っています。一方、Configの中にはメタデータだけでなく、ビルド履歴やrootfs/diff_idsというフィールドが入っていて、これは「非圧縮レイヤ」の論理的な識別子として使われます。このdiff_idsと、manifest側のLayersに並んでいる「圧縮済みレイヤ」のハッシュを組み合わせることで、「どのファイルがどのレイヤに属しているか」「どこまでが共有できるか」という判定が行われる。記事では、各レイヤtarを実際に展開してみて、ベースイメージ由来のファイルと、後から追加したファイルが別々のディレクトリに現れ、それがLayerFSによってLowerDirとUpperDirとして統合され、コンテナからはMergedDirとして一つのファイルシステムに見えている、という流れも丁寧に追っています。普段は意識しない“Dockerイメージの実体”を、自分の手で剥がしながら理解していくプロセスが描かれていて、「なんとなく使ってたけど、裏側を知るとちょっと怖さも減るな」という、学び直しにぴったりの記事でした。
……ということで、今日は全部で5本、
1本目「生成AIでパワポを作る方法一覧」、
2本目「課題ベースで学ぶClaude Code便利機能」、
3本目「Claude Codeのガードレールには3つのレイヤー」、
4本目「ClaudeCodeでSimulinkを操れるか」、
5本目「Dockerイメージを深掘りしてみる」、
このラインナップでお届けしてきました。
気になる記事があれば、番組のショーノートに詳細を書いておきますので、あとでゆっくりチェックしてみてください。通勤前の準備をしながら、会社に着いてから、あるいは帰りの電車の中で読み始めてもいいかもしれません。
「zenncast」では、番組の感想や、「こんなテーマを取り上げてほしい！」といったリクエストもいつでも募集しています。この記事おもしろかったよ、とか、ここもっと深掘りしてほしい、なんて一言でも大歓迎です。
それでは、そろそろお別れの時間です。
今日も一日、無理しすぎず、ほどよくサボりつつがんばっていきましょう。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。いってらっしゃい。