今年の1月に契約のGLM Light Planで GLM 5.2 が使える用になったので、モデルを切り替えてみた。
Grok曰く、ベンチマーク的には現在メイン利用の gpt-5.4-mini よりパフォーマンスに優れるとのことなので、活躍に期待したい。
cat ~/.config/opencode/opencode.json
{
"$schema": "https://opencode.ai/config.json",
"plugin": [
"oh-my-opencode@3.11.1"
],
"model": "zai-coding-plan/glm-5.2"
}
というプロダクトが2026年2月頃に発表されていたのを今更知った。
https://docs.docker.com/ai/sandboxes/
内部的には、Micro VM用のVMMを自作して使っているらしい。FirecrackerはmacやWindowsの上で動作することを想定してないプロダクトなので不採用としたとのこと。
https://www.docker.com/blog/why-microvms-the-architecture-behind-docker-sandboxes/
VMとMicro VMの違いはなんぞ？とかMicro VMという選択肢の優位性は？というあたりが気になる。けど、そのあたりは昔書いたFirecrackerの記事をベースに理解しておけば良さそう。選択肢としてWASMが増えたけどそれ以外はそこまで問題空間が変わっていないように見える。
https://blog-smatsuzaki.hatenablog.com/entry/2020/11/29/132038
Coding Agentをサンドボックスの上で動かしたいとしてComputeはコンテナがいいのか？Micro VMがいいのか？ が一つの論点に思う。セキュリティ面で見るとisolationはMicro VMの方が得意だ。反面、軽量さ/省リソース性という観点で考えるとMicro VMはContainerよりもずっと重い。host machineとは別にkernelを起動するのだから。なので、起動の速さも当然遅くなる。そこのあたりをどう考えるのか？だろうか。
友人がcmuxを使っているのを見て羨ましがっていたら、herder.devがでできた。 これならWSL2でも動く！とのことでとりいそぎインストール。
しばらく使ってみる。
PCI DSSに興味を持ち、ネットワークセグメンテーション、マイクロセグメンテーションなどの概念を復習する中で「そもそもセグメンテーションってどういう概念だっけ？」となって考えたことのメモ。
まず、 セグメント(segment) という言葉の意味合いから。Oxford Learner's Dictionariesで segment の意味を引くと以下と説明されている。
a part of something that is separate from the other parts or can be considered separately
これを踏まえると、言葉の含意は以下となる。
具象的なイメージは以下のようになるか。
分けること = 守ることだから。より詳細には、境界によって外部と内部を分け、外部から内部への侵入を難しくすることで内部の安全性が向上するから。
「外側」には「攻撃」をしかけてくる「脅威」がいる。それに対して「安全」を確保するためには、「境界(壁)」を作り「脅威」が「内側」に入ってこない状態を作る必要がある。
つまり、「安全」を確保するための手段として「境界(壁)」がある。
※ 危険な存在が入ってこれない空間の確立 = 安全の確保、という発想 ※なので、「境界を作ることで、脅威をもたらす外敵が入ってくることのできない安全な空間(内側)を作り出すこと」がセキュリティの文脈におけるセグメンテーションの本質と考えてよいと思う。
境界が１つだけだと突破されたらゲームオーバー(安全が崩壊) するから。
なので境界を１つではなく、複数用意すれば...
漫画『進撃の巨人』より
壁が1つ突破されたとしても、まだ安全な領域は残る。
日本の昔のお城の構造も同様の構造を採用している。
お城は２つの要素で境界を成り立たせている。
そして、万里の長城みたいに「一つの巨大な壁が外と内を分ける」設計思想を採用していない。むしろ、「複数の境界により複数の空間（セグメント）に地形を分割する」ことを志向している。
これは、「複数の安全な空間があれば１つの空間が敵に占領されてしまっても、別の空間に後退することで、脅威からの防衛・安全確保を維持することができる」という思想に基づいている。
※このような考え方は縦深防御・多層防御(defence in depth)と呼ばれている。。
境界によって空間を分割し、安全な空間を作り出す ことClaude Code Pro Planの5h limitをすぐに使い切る...ということで、z.AIのGLM Coding Planを契約した。
※一番左のプランを契約した。
z.AI社はCLIのAgent Codeing Tool(Agentハーネス)を提供していない。
当初、Claude Codeで使おうとしたが、Claude CodeのPro Planと共存できない（Claude Code自体もPay as you goになってしまう)ことがわかったのでopencode + oh-my-opencodeを使うことにした。
というわけで掲題の通り、初期設定を実施する。
公式ドキュメントにそのものずばりな記述があるのでそれをそのまま書いてあげればいい。
具体的には、 ~/.config/opencode/opencode.json に以下のようにpermission ruleを追記する。
{ "$schema": "https://opencode.ai/config.json", "permission": { "read": { "*.env": "deny", "*.envrc": "deny", "*.env.*": "deny", "*.env.example": "allow" } },
opencodeを起動して、 .env の読み取りを依頼。読み取りに失敗することが確認できればOK。
Xを見ていて気になったトピック。
https://x.com/elonmusk/status/2014501663776588200?s=61&t=3D8aey3mzaGy9asl-hQRHw
チャットから指示が出せるタイプのPersonal Assistantなんだとか。
https://github.com/clawdbot/clawdbot
エージェント向けターミナルとのこと
利用を再開して、2日が経過した。昨日は、Codexの GPT-5.1-codex-mini が1Hぐらい苦戦して進捗の出なかったバグを Sonnet 4.5 が10分くらいで解決して感動した。
コードレビューには、Gemini Code Assistantを使っている。
(1) GitHubのPRに画面に /gemini review と投稿し、Geminiのレビューをキック
(2)gh コマンドでレビューコメントをClaude Codeに確認し修正してもらう
を繰り返すイメージ。
試作アプリのDBにsqliteを使うことが多い。その際の、データの閲覧方法に困っていたが sqlite viewer がよさそうなので、しばらくこれを使おうと思う。
最近、よく聞くようになった言葉なので、概念を理解しておきたい。
...というのを初めて知った。以下のように書けばいいみたい。
<details> <summary>Click to expand</summary> whatever </details>
参考 : Collapsible contents (code block) in comments / spoiler tag
gpt-5.2-codex でずっと回していたが、週次の仕様枠の消費があまりに激しいので、gpt-5.1-codex-mini に変えた。しばらくこれで様子を見る。
ぼちぼち使い始めた。こちらのXの投稿を見て、ccstatuslineを入れてみた。細かいconfigurationはこれから。
「色々と手を動かしているんだけど、振り返れていないよね」という課題感があるので、個人的な週報を運用してみるのはありかもと思っている。ので、参考リンクを残しておこうと思う。
dailyのtodo管理はObsidianでやって、安定しているのだけど、もう少し俯瞰的に1週間あるいは1か月で何ができたのか？方向性は合っているのか？をPlan, Reviewできるようにしたい。色々と試行錯誤していこう。
Codexをもりもり使っていることもあり、使用を再開してもいいのではと思い始めている。以下の記事にショートカットが網羅的にまとめられているので、これをみながらちょっとずつ覚えていけばよさそう？
OpenCodeで無料で使えるLLM Model, GLM 4.7の話題をXで聴く機会が増えた。中国のZ.aiという会社が開発しているみたいなので、名前を覚えておく。
会社概要
https://en.wikipedia.org/wiki/Z.ai
これは、本当にそうだなと思った。Vibe Codingの難しさの主要因の一つだと思う。
今までこのブログは1記事=1topicで書くことが多かったけど、Simon Willsonさんのブログを読んでいてもう少し日記よりでもいいのかもと思ったので、しばらくそのスタイルを試してみようと思う。
XでChromiumのソースコードにAI向けのアセットが含まれているという話を見かけて、chromiumの公式repositoryをのぞいてみたけど、確かに .claude .gemini agents などそれらしいディレクトリがあった。時間のある時に、どういう書き方の工夫がなされているか、研究してみるのもいいかも。
Claude CoworkがProプランでも使えるようになった。そろそろ、契約しようかな。。Claude Code + OpenAI Codexのコーディングパターンも試したいし。
「インフォグラフィック風の画像生成といえば、Geminiという印象があったけどChatGPTはどうなんだろう？」と思い生成をお願いしてみた。悪くない。たくさん、いろんなテーマでChatしていると認知負荷が高いので、会話の内容をどんどん画像にしてもらい、認知負荷を下げていくのはありかもしれない。
海外のtech記事を読んでいると、deepdive という言葉とならんで under the hood という表現がよく出てくる。
※例 -> Kubernetes under the hood
で、「hoodって何？」ということはあまり考えてなかったのだけど、hood というのは要するに車のボンネットのことのようだ。
A car hood, also referred to as a “bonnet” in some countries, is the hinged cover that rests over the engine bay of a front-engine vehicle.
なので、上記で例として出したk8sの記事の挿絵にもある通り、「ボンネットを開けて、内部構造を見る・学ぶ」というメタファ表現なんですかね。
外国語を学ぶときは、できるだけ「絵」 == visual mageで単語の意味を覚えた方がいいと思うので頭の片隅においておく。
友人に教えてもらったoh-my-opencodeを少し試用してみた。
OpenAI Codexについては使ってもリスク低そうな状況に見えたので、バックエンドに設定してみた。
触ってみた雑感だけど、 multi-agent的な思想が強く、司令塔の Sisyphus 人格が、他のagentにbackground taskをガンガンデリゲーションしていく動きが新鮮だった。
あと、opencode側の機能になるが、slash command /init を実行すると AGENTS.md を自動生成してくれるのはなかな便利だなと思った。暫く試用してみる。
You can now use your GitHub Copilot subscription with @opencode 🙌 pic.twitter.com/hhgy2GxbiL
— GitHub (@github) 2026年1月15日
以下の記事を見て興味を持ったので、OpenAI Codex CLIで試してみた。
~/.codex/config.toml に以下行を追加[mcp_servers.aws-knowledge-mcp-server] command = "uvx" args = ["fastmcp", "run", "https://knowledge-mcp.global.api.aws"]
codexコマンドでcodex CLIの対話モードに入る
/mcp で正常に起動され、 Status: enabled となっていることを確認tools:aws___list_regionsを実行して と依頼し、toolsの実行に成功することを確認使ってみてわかったが、document searchをしてもらう場合はpromptの末尾に 引用（citations）マーカーを出力しないで。URLは必要なら本文にそのまま書いて。 を付けないとdocのurlが文字化け？する。
prompt
AWSのECS Fargateでの、credentialなどの秘匿情報管理の公式ベストプラクティスを探して。引用（citations）マーカーを出力しないで。URLは必要なら本文にそのまま書いて。
result
• 以下は、AWS 公式ドキュメントに基づく「ECS Fargate における credential 等の秘匿情報管理のベストプラクティス」です。引用マーカーは出力せず、必要な URL は本文に記載します。要点は Fargate でも同様に適用される
ECS の公式ガイドに基づきます。
事実（公式ドキュメントに明記）
- 秘匿情報（API キー、DB 認証情報など）は特定の IAM プリンシパルに限定し、コンテナ起動時に注入することが推奨されています。https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-secrets-
management.html
- VPC エンドポイントを利用して Secrets Manager / Parameter Store へ私設接続することが推奨されています。https://docs.aws.amazon.com/AmazonECS/latest/developerguide/secrets-envvar-secrets-manager.html
- ECS の公式ベストプラクティス文書では、Secrets を安全に保存し、IAM によるアクセス制御とローテーションを行うことが推奨されています。https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/security-
secrets-management.html
- AWS Well-Architected Framework では、ハードコードを避け、Secrets Manager 等の専用サービスを使い、アクセス制御・監査・ローテーションを行うことが推奨されています。https://docs.aws.amazon.com/
wellarchitected/2024-06-27/framework/sec_identities_secrets.html
観察（上記事実からの解釈）
- Fargate でも ECS の公式 Secrets 管理手法（Secrets Manager / Parameter Store + Task Execution Role）が標準的なベストプラクティスと整理できます。
- 秘匿情報の注入方法として環境変数は一般的ですが、ローテーション反映には再デプロイが必要であり、運用設計が重要です。
- VPC エンドポイントの利用は、秘匿情報アクセス経路の露出を抑える公式の実装上の推奨と解釈できます。
推論（必要に応じた補足推論）
- Fargate タスクの Secrets 取得はネットワーク到達性に依存するため、VPC エンドポイントの設置有無が可用性・セキュリティ両面で重要な設計要素になると推定できます。
必要であれば、Fargate 向けに「タスク定義の具体例」「Execution Role ポリシー最小権限例」「Secrets Manager/Parameter Store の使い分け」まで公式記載に基づいて整理します。
「GoogleのAIが賢くなってきたし、そろそろ、調査＆リサーチ結果をGoogle Slideに出力まで1 requestでできないかな」と思ったので、実験してみたメモ。
3パターン試した。
gemini.google.com で依頼gemini.google.com が生成の結果を、Notebook LMのテキストに渡し Stdio 機能で スライド資料 を生成gemini.google.com で依頼「私は、ユーザー様のGoogle Drive内のファイルを作成、編集、またはアップロードする機能を持っておりません。」との返答があり、生成に失敗。
「Right now, I can only create one slide at a time. 」との返答があり、Google Slideファイル全体の生成には失敗。 ※1Pだけなら生成してくれそう？
gemini.google.com が生成の結果を、Notebook LMのテキストに渡し Stdio 機能で スライド資料 を生成この方法だけが、Slideファイルの生成に成功した。成果物をダウンロードしてみたら、pdf形式だった。
現時点では、NotebookLMを使うのがよさそう。後日時間があれば、felo.aiも試してみたい。
Obisidianのデフォルトのsyntax highlighterに不満があり*1、「もっといいものないかな」と探してたところ、redditのスレッドで Shiki Hilighter なる代替ツールがあることを知った。
このプラグインはObsidiaianのcode blockのレンダリングをデフォルトのPrism.jsから、Shikiに切り替えてくれる。
redditでの評判がとてもよかったので試しに入れてみたら、今まで色が一切つかなかったbashのコマンドがハイライトされて感動した。
標準のコードブロック以外に、オプション的な記法がいくつか用意されている。
入力
レンダリング結果
入力
レンダリング結果
入力
レンダリング結果
入力
レンダリング結果
当初dark系のthemeを使おうと思ったが、 title 記法を使うとファイル名が黒背景上に黒字になり、視認性が悪いので断念した。代わりに、 Solarized Light を使うことにした。
以下にて、documentationされている。
好印象なので暫く使ってみる。
年末年始の帰省のために新幹線を予約したので、Googleカレンダーに予定を転記しようと思い、せっかくだからLLMにやってもらうことにした。
Google系サービスの操作については、Geminiを使うことがベストプラクティスなのかもしれない。※Google社のサービスの操作だから当たり前な気もしつつ
以下の予定をGoogle Calendarに登録してほしい。
注：画像は以下から持ってきたダミー画像です。 https://expy.jp/reservation/reserve_exic/
画像の情報を元に、xxxx年xx月xx日(xx) xx:xx発の「のぞみxxx号（xx - xx）」の予定をGoogleカレンダーに登録しました。 (以下略)
カレンダーに直接書き込むことはできないけれど、コピペすればそのまま登録できる形で用意するね。 (以下略)
