どうも、こんばんは。マイクです。
今日も「zenncast」のお時間やってまいりました。
今日は2026年4月29日、水曜日の朝7時。みなさん、そろそろ仕事前の支度してる時間でしょうか。それとも夜勤明けでおつかれさま、なんて方もいるかもしれませんね。
この番組では、Zennで話題になっているトレンド記事をピックアップして、ラジオ感覚でゆるっと紹介していきます。通勤や作業のおともに、耳だけでキャッチアップしていきましょう。
さて、今日はですね、全部で5本の記事をご紹介していきます。AIコーディング、キーボード配列、型安全なWeb開発、AIエージェントの安全運用、そして会社アカウントとAIの付き合い方まで、かなり濃いラインナップですよ。
それじゃあ早速いきましょう。まず1本目。
タイトルは「非エンジニアの『作りたい』と『安全に公開したい』を両立する Sandbox MCP を作った」。
これね、「AIでアプリは作れたけど、これどうやって社内に安全に公開すればいいの？」っていう、まさに現場の悩みにド直球で答えてる取り組みなんですよ。
AirClosetさんが作った「Sandbox MCP」は、Claude Codeと会話しながら作ったアプリを、そのまま社内に安全に公開するための“土台”になってます。
何がすごいかって、UIのデザインは用意されたUIキットで統一されていて、Dockerfileは自動生成、デプロイ先はCloud Run、認証はCloudflare ZeroTrust、データはFirestoreにユーザーごとにきっちり分離して保存、っていうところまで、ワンコマンドで行けちゃうんですね。Webアプリも、APIも、バッチ処理もカバー。開発中はlocalStorageで軽く試して、本番に上げると自動でFirestoreに切り替わる、という気の利きよう。
インフラ側も工夫されていて、ワイルドカードDNSとCloudflare Worker、それから自前Gitサーバを使うことで、とにかくサクッと公開できるようにしている。大きなアプリはgit pushベースで反映して、AIのトークン消費も抑える、っていう実務的な配慮までされています。
そして肝心のセキュリティ。
①Cloudflare ZeroTrustで入口を絞る、
②MCP側のOAuthで「自分のアプリだけ触れる」という制限をかける、
③Firestoreの名前空間と専用DBでユーザーごとにデータを分ける、
④Cloud RunのサービスアカウントとIAMで、最小権限に絞る。
この4層構造で、「AIで誰でも作れるけど、公開と安全性はプラットフォームが守る」という世界観を実現しているんですね。
さらに、MCPツールのdescriptionに「UIの使い方」「DBの使い方」「デプロイ手順」まで全部書き込んで、AI自体が“正しいフロー”を自律的にたどれるように設計しているのも面白いポイント。非エンジニアの人が、自分で業務改善ツールをどんどん作れるように背中を押している、そんな記事でした。
。。。。
続いて2本目。
タイトルは「40%キーボードに移行する前に知っておきたかったこと」。
いわゆる30〜40％キーボード、キーの数をギューッと削ったコンパクトな自作キーボードの話ですね。エンジニア界隈だと「片手5カラム」とか、かなり攻めたレイアウトが流行ったりしますが、「いや、それちょっと待った方がいいかもよ」という、筆者のリアルな経験談になっています。
特に焦点になってるのが、親指の酷使とTap&Holdの誤爆。
40％周辺の世界だと、スペースバーの代わりに、親指の位置にレイヤー切り替えやShift、Metaキーなんかを詰め込みがちなんですよね。で、その状態で高速タイピングをすると、Tap&Holdの判定ミスでショートカットが暴発したり、親指だけ異常に疲れたりして、最悪腱鞘炎のリスクも出てくる。
特に片手5カラムみたいに極端な配列だと、Metaキーを親指以外に逃がす余地がほとんどなくて、レイアウトの自由度がガクッと下がる。筆者は「6カラムで、小指にもMeta系を持たせた方が、まだバランスよく設計できるよ」と主張しています。
対策としては、
・親指にホールドキーを詰め込みすぎない、
・Shiftやレイヤー切り替えと、その後に打つキーは「別の手」で押す前提でレイアウトする、
・Cmd/Alt/Ctrlみたいな“危険な修飾キー”は、TAPPING_TERMを長めにしてホールド扱いされにくくする、
といった運用のコツが紹介されています。
結局のところ、「最適なレイアウトは手の形や癖によって全然違うから、他人の設定を鵜呑みにしないで、自分の身体と相談しながら調整しよう」という締め方になっていて、自作キーボード沼の“落とし穴”を先に教えてくれるような、ありがたい記事でした。
。。。。
では3本目。
タイトルは「Hono × Inertia.js が作る新しい型貫通体験に触れてみた」。
これはWebアプリの開発体験のお話ですね。Inertia.jsという仕組みは、サーバーがAPIではなく「どのコンポーネントを、どんなpropsで描画するか」という“page object”を返して、クライアント側がそれをそのままSPAとして描画する、という考え方になっています。LaravelやRailsと組み合わせた“モダンなモノリス構成”と相性がいいと言われているやつですね。
この記事では、それをHonoとTypeScriptで使うことで、「サーバーからクライアントまで、propsの型を完全自動で貫通させる」っていうところにチャレンジしています。
具体的には、Hono側の`c.render`の戻り値に`TypedResponse`を仕込んでおいて、Honoの`ExtractSchema`機能で全ルートのoutputを型として抽出する。それをViteが生成する`AppRegistry`と組み合わせることで、クライアント側の`PageProps<C>`から「このページコンポーネントには、こういうpropsが来るはずだよね」という型を自動で取り出す、という仕掛けになっています。
これによって、Laravel/Rails＋Inertiaの定番構成でありがちな「サーバー側とクライアント側で同じスキーマを二重定義しちゃう問題」とか、「propsの型を手で書き続ける問題」から解放される。ページ名をタイプミスしたらコンパイルが通らないので、バグも早期に気づける。
tRPCと比較すると、tRPCは“関数1個1個”、つまりAPIの手続き単位で型を流していくのに対して、Inertiaは“ページ全体”を単位にしている。この粒度の違いがあって、特に「ページごとに状態が完結している業務アプリ」では、Inertia型の発想の方が自然だったりする、という話も面白いところです。
この記事で紹介されている仕組みは、すでに`@hono/inertia`として公式ミドルウェア化が進んでいて、なんと60行程度の薄いアダプターで、この“型が端から端までちゃんと届くSPA体験”を実現しているそうです。型好きなエンジニアにはたまらない内容でした。
。。。。
4本目いきましょう。
タイトルは「97%のPermission確認を自動化するCoding Agent用OSS『ccgate』が誕生した」。
これは、Claude CodeとかOpenAIのCodex CLIみたいなコーディングエージェントが、ツールを実行する前に「これ、本当にやっていい操作？」って毎回聞いてくる、あのPermission確認をどうにかするお話です。
ccgateは、そのPermissionRequestのフックに挟み込むCLIツールで、「この操作は許可する」「これは危険だから拒否」「判断が微妙だから人間に回す」という3つの判定、`allow`・`deny`・`fallthrough`を、別のLLMにさせてしまう仕組みになっています。
ルールはjsonnetで自然言語ベースに書けるようになっていて、たとえば「read-onlyな調査」や「プロジェクトで定義されているtest・lintの実行」は通してOK。一方で、`curl | bash`とか、バージョン固定されていない`npx`や`pnpx`、force push、リポジトリ外のファイル編集といった“危険な操作”は自動的にブロック。判断が難しいものだけ人間に戻す、という形で、エージェントの自由度と安全性のバランスを取っています。
面白いのは、denyしたときに返すメッセージの中で、「こうすれば安全にできるよ」という改善指示も一緒に返せるところ。単に「ダメ」って言うだけじゃなくて、「ここをこう直して」まで含めてAIに教えられるので、エージェントがだんだん“いい子”になっていくイメージです。
Claude CodeのAuto ModeやCodexのauto_reviewとは別系統で、外付けの“ゲート”としてPlan modeやCodex CLIにも共通ポリシーを適用できるようになっていて、さらにmetrics機能でログを取りながらルールの精度を上げていける。筆者の環境では、Permission確認の94〜97％を自動化できていて、「とりあえず全部聞かれる問題」「プロンプト疲れ」をかなり解消しつつ、安全側に寄せた運用ができているそうです。
「AIに任せるところを増やしつつ、人間の“最後の確認役”は外さない」という、これからの開発スタイルを象徴するようなOSSでした。
。。。。
そしてラスト、5本目。
タイトルは「AIに会社のGoogleアカウントを渡していませんか」。
これは、会社のGoogle WorkspaceとAIを連携するときに、「ユーザーの権限を、そのままAIに丸ごと渡してない？」という、ドキッとする問いかけから始まる記事です。
たとえば、1on1のメモとか、個人的なメモ、機密度の高いドキュメント。人間としては「これはAIに見せたくないな」と感じるものまで、アカウントの権限をそのまま渡していると、技術的には全部AIの視界に入ってしまう可能性があるんですね。しかも監査ログ上も、人間の操作とAIの操作が区別できない。これだと、どこまでAIが読んだのか、あとから追いづらい。
この記事で紹介されているアプローチでは、ユーザーごとに「AI専用のサービスアカウント（SA）」を1個ずつ発行して、そのSAに共有したリソースだけをAIが見られるようにする、という設計をとっています。つまり、「ユーザーに見えるもの」と「AIに見せていいもの」を分離するわけですね。
これによって、権限管理やDLP、監査はGoogle側の標準的な共有・認可の仕組みに乗っかりつつ、「AIの視界」をユーザー自身が能動的に絞り込めるようになる。MCPassという仕組みでは、このSAの発行をボタン一つでできるようにしていて、ユーザー単位のSA＋MCPごとのスコープ制限、発行者用SAと実行者用SAの二層構成、マルチプロジェクトでのクォータ対策なんかも盛り込まれています。
さらに、Googleトークンの発行権限はInterceptor層に閉じ込めてしまって、LambdaからWIFを経由して管理用SA、そこからユーザーSAへと権限を委任して、短命トークンを鍵レスで発行する、という“細いパイプ”構成にしている。MCPサーバー側は「渡されたトークンで動くだけ」のステートレス設計にしておくことで、万が一どこかが破られても被害を最小化しやすくしています。
まとめると、「AIにはAI専用の身分証をちゃんと発行して、その発行と利用範囲を厳密にコントロールしよう」という話ですね。便利さだけを追いかけると見落としがちなポイントを、かなり具体的な設計で教えてくれる記事でした。
。。。。
というわけで、今日ご紹介したのは全部で5本。
非エンジニアでも安全に社内アプリを公開できる「Sandbox MCP」の話、
40％キーボードに飛び込む前に知っておきたい、親指とTap&Holdのリアルな話、
Hono × Inertia.jsでサーバーからクライアントまで型が貫通する新しい開発体験の話、
コーディングエージェントのPermission確認をほぼ自動化するOSS「ccgate」の話、
そして、会社のGoogleアカウントとAIの付き合い方を再考させてくれる、サービスアカウント設計の話。
気になった記事があった方は、ぜひこのあとショーノートから元の記事もチェックしてみてください。ここではざっくり雰囲気をお伝えしましたが、本編には図やコード、より詳しい設計の話がぎゅっと詰まっています。
「zenncast」では、番組の感想や「こんなテーマ取り上げてほしい！」といったリクエストもお待ちしています。普段どんなシーンで聞いてるのかなんかも教えてもらえると、マイクのトークのテンション調整の参考になります。
それでは、そろそろお別れの時間です。
次回も、Zennのトレンド記事を一緒にゆるっと追いかけていきましょう。
お相手はマイクでした。それではみなさん、いってらっしゃい、そして行ってきます。