どうも、マイクです。おはようございます。
二千二十六年九月二十五日、金曜日の朝七時を回りました。
ここからの時間は「zenncast」、きょうもZennで話題になっているトレンド記事をゆるっと、でも内容はみっちりお届けしていきます。

きょうは全部で五本の記事をご紹介していきます。技術寄りの話もあれば、自宅サーバーとかAIのちょっと夢のある話まで、幅広く揃ってますので、お好みのところで耳を傾けてみてください。

では、さっそく一つ目いきましょう。
一つ目は、自宅サーバーの魅力と始め方を紹介している、オピニオン寄りの記事です。

筆者の方は、昔使っていた古いゲーミングノートパソコンを再利用して、自宅サーバーとして運用しています。そこにLinuxを入れて、そのうえにCasaOSという、初心者にも扱いやすいサーバー管理の環境を載せているんですね。
この経験から、自宅サーバーっていうのは、余っているパソコンを活用して、「学習」と「生活」の両方を豊かにできる環境だ、というふうに説明しています。

開発者目線で言うと、Linuxの基本操作はもちろん、Dockerでのコンテナ管理、それからDHCPやDNS、Pi-holeみたいなネットワーク関連の設定まで、実際の機械を触りながら学べる、最高の教材だよと。
しかもそれが、ただの勉強で終わらず、日常生活にも直結してくるのがいいところなんですね。

たとえば、
・Immichを使って写真のバックアップを自分のサーバーに集約したり、
・Home Assistantでエアコンを自動制御して、家をスマートホーム化したり、
・Pi-holeで家じゅうの端末の広告を一括ブロックしたり、
・OllamaとOpen WebUIを使って、ローカル環境でAIを動かしたり、
こういったことを全部「自前」でやっちゃうことで、クラウドサービスの代わりにもなるし、プライバシーも守りやすくなる、と強調しています。

スタートラインも意外と低くて、中古のパソコンや押し入れで眠っているマシンが一台あればオーケー。あとはネットに転がっている動画チュートリアルを見ながら、少しずつ構築していけばいいと。
なにより筆者が言っているのが、「いじるのが楽しい」というところ。トラブルも含めて、自宅サーバーを触る時間そのものが、技術的な学びと趣味の両方を満たしてくれる、おすすめの遊び場ですよ、という締めくくりになっていました。

。。，。

続いて二つ目。
こちらは、Claude Opus ファイブ・ポイント・ファイブというモデルに、「サンゴ礁の一日」をテーマにしたピクセルアニメーションを作らせてみた、という検証系、オピニオン寄りの記事です。

お題がなかなか無茶ぶりで、「外部ライブラリや画像素材は一切ナシ」「単一のHTMLファイルだけ」で、しかもサンゴ礁の生態系を、それなりに自律的に動くアニメーションとして表現してくれ、というリクエストなんですね。
プロンプトの中では、昼と夜のサイクルをどう変化させるか、小魚の群れの挙動、いわゆるボイドの動き方、サメが近づいてきたときに魚たちがどう逃げるのか、タコがどう擬態するのか、そういう細かなルールをすべて文章だけで指定しています。

途中でユーザーがやった修正もすごくシンプルで、「昼夜周期を九十秒から二十秒に短くしてほしい」という一行を追加しただけ。
それに対してClaudeが出してきたのは、横三百二十ピクセル、縦百八十ピクセルのCanvasを使って、およそ三十色の共通パレットを定義しながら、レイヤー分けやディザリングまで駆使した、かなり本格的なコードだったそうです。

アニメーションとしても、群れがただ動くだけではなくて、いったん分散して、また集合する、夜になると岩陰に隠れるといった、条件に応じた複雑な相互作用がきちんと実装されていて、「これ本当に自然言語の指示だけで作らせたの？」というレベル。
さらに面白いのが、プロンプトに書いてない要素──ウツボやチンアナゴ、タコの墨の表現なんかを、Claudeが自発的に追加してきた点です。

この記事のポイントは、「自然言語だけで、けっこう高度なアニメーションと挙動設計まで任せられるところまで来ている」と同時に、「とはいえ、これはあくまで一発うまく行った例かもしれないので、再現性の検証はこれからだよね」という冷静なまとめ方をしているところ。
一回の成功事例に飛びつきすぎず、でも可能性はかなり感じるよね、というスタンスで、実験の内容を丁寧に追いかけてくれている記事でした。

。。，。

三つ目の記事です。
ここからは新しいAIモデル「Jev（ジェブ）」を紹介する、サービス紹介寄りの内容になります。

JevはTypeSafe AIというところが開発している、「System Oneモデル」と呼ばれるタイプのAIです。特徴的なのは、ふつうの大規模言語モデルみたいに文章を書かないところ。
Jevが返してくれるのは、「状態」と「決まった形式の質問」に対して、「確率付きの判断」だけ、というかなり割り切った設計になっています。

具体的には、三種類のタスクに特化しています。
ひとつめが「イエス／ノー」の判定。
ふたつめが「用意された選択肢の中から一つを選ぶ」タイプの分類。
みっつめが「段階評価」、たとえば一から五段階でのスコアリングのようなものですね。

出力はすべて数値やIDで返ってきて、人間が読む文章は基本的に出てきません。完全に「プログラムが読む前提」のインターフェースになっていると。

メリットとして強調されているのが二つあって、ひとつは「LLMと比べて桁違いに速くて安い」こと。もうひとつが、「確率の較正」がちゃんとされていることです。
たとえば、Jevが「〇・八五です」と言ったときは、本当におおよそ八十五パーセントぐらい当たる、という感じで、確率の数字と現実の当たりやすさが揃うように調整されている。
このおかげで、自動化のワークフローにそのまま組み込みやすく、「〇・七を超えたら自動で処理する」「〇・五以下なら人間に回す」といった線引きがやりやすいんですね。

使いどころとしては、問い合わせの分類、エージェントのガードレールとして「これは危険そうだから止める」といった判定、lintやテストケースの優先度づけ、大量データを一括で判定してふるいにかける処理、さらにはリアルタイムでゲームの操作を判断するとか、「とにかく細かい判断を大量かつ高速にさばく用途」に向いています。

一方で、できないこともはっきりしていて、文章生成はしないし、計算もやらない、情報抽出もやらない、画像や音声も扱わない。あくまで「LLMの周辺で判断だけやる専用ツール」という位置づけだと。
内部構造は非公開で、公式の性能比較資料も、どうしてもバイアスは入りうるので、実際に導入するなら自分たちのデータで精度と確率の信頼性を検証するべき、と注意を促しています。

そして最後に、「どこまでを自動で任せるか」はちゃんと慎重に決めようね、というまとめ。
「なんでもAIにお任せ」ではなくて、人間の監視やダブルチェックをどう残すかまで含めて設計することが大事だ、という視点をしっかり示してくれている記事でした。

。。，。

では四つ目。
ここからは、AWS DevOps Agent のセキュリティを検証した、オピニオン寄りの技術考察です。

筆者は、強い権限を持つ「Elevated Role」と、「Directed Actions」という仕組みを組み合わせると、どこまで危ないことができてしまうのか、という観点で実験をしています。
具体的には、任意コマンドの実行、不正なパッケージの導入、バックドアの設置といった攻撃シナリオが、どこまで現実的なのかを確かめているわけですね。

結果として、DevOps Agentそのものはかなり厳しめに作られていて、任意のシェルを叩くような操作や、怪しいパラメーター注入の多くは事前にブロックされる、と。
一方で、抜け道がゼロというわけではなくて、たとえば事前に置いておいたプログラムを「保守用ツールです」と偽装して起動させたり、Security Groupの変更と組み合わせることで、外部から接続できる経路をこっそり作ってしまう可能性がある、といった指摘をしています。

ログまわりについても触れられていて、CloudTrail側では、UpdateApprovalAction、AssumeRole、SendCommandといったイベントを追っていけば、だいたい行為の流れは追跡できる、と。
ただし、AgentがAPIを呼び出す前に「これはダメ」と拒否した試行については、痕跡がかなり薄くなりがちで、何をやろうとしていたのかが見えにくい。

さらに厄介なのは、DevOps Agent経由の攻撃だと、CloudTrailのsourceIPAddressが `aidevops.amazonaws.com` として記録される点です。これだと、攻撃者本人のIPアドレスが隠れてしまう格好になるので、インシデント対応のチームがこの仕組みをちゃんと理解していないと、「なんとなくAWSの中から来てる？」ぐらいに見えてしまい、攻撃を見逃しやすい、と強調しています。

そのうえで本番運用のベストプラクティスとしては、
・Directed Actionsを使う範囲をできるだけ限定すること、
・Elevated RoleとPermissions Boundaryを最小限に絞ること、
・危険なSSM Documentはあらかじめ禁止しておくこと、
・重要な操作はロールを分離して、一人の権限で完結しないようにすること、
・AccessDeniedのログもちゃんと監視して、「攻撃の試行」段階から気づけるようにすること、

こうした多層防御とログ監視を前提にした設計が欠かせない、とまとめています。
「便利なAgentだからこそ、権限設計とログの見方まで含めて理解してから使おう」というメッセージが込められた記事でした。

。。，。

そしてきょう最後、五つ目の記事です。
こちらはClaude Codeの「自動メモリ」機能との付き合い方、いわば「メモリ掃除」のススメ、という内容になっています。

Claude Codeでは、同じリポジトリで使い続けていると、自動メモリがどんどん溜まっていって、`MEMORY.md` というインデックスファイルに蓄積されていきます。
ところが、この `MEMORY.md` の先頭、おおよそ二百行、もしくは二十五キロバイトを超えた部分については、事実上読まれなくなってしまう、という性質があるんですね。
つまり、頑張ってフィードバックを書いても、一定量を超えると「末尾の方はほぼ見られていない状態」になりがちだと。

そこで筆者は、人間側で定期的に「メモリ掃除」をしよう、と提案しています。
やり方としては、まず `MEMORY.md` を読んで、「これは毎回ちゃんと守ってほしい」と思う内容を抜き出して、`.claude/rules` ディレクトリに移してあげる。メモリに残しておくのではなく、ルールとして昇格させるわけですね。

この掃除の流れは二段構えになっていて、
まず、自作のスキル `/memory-compaction` を使って、溜まりまくっているメモリ群を、読みやすい量に統合・圧縮します。
そのうえで、`/rule-creator` というスキルを使って、重要なフィードバックを「一トピック一ファイル」の形でルール化していく。
こうすることで、「これはこのプロジェクトでの大事な方針だよね」という内容を、きちんと構造化したルールとして管理できるようにする、という発想です。

ルールファイルは `.claude/rules` の中に細かく分割して置いておいて、説明が長すぎるものや具体例がてんこ盛りのものは、`.claude/references` に退避させる。
ルール側から参照としてリンクしておけば、必要なときにだけ詳しい資料を読ませることができます。

筆者は一度、このルール群をスキルとして「必要なときだけ読んで」と指示する方式も試してみたそうなんですが、その場合ほとんど発動せず、あまり役に立たなかったとのこと。
最終的には、重要なルールは「常駐ルール」に戻しておいたほうがよくて、そうするとAIが先回りして気を利かせてくれるケースがぐっと増えた、という経験談も紹介されています。

また、ルール読み込みにはキャッシュが効くので、毎回全部読ませているように見えても、実際のコストはそれほど高くないらしいんですね。
なので、「ルールを減らそう減らそう」と頑張るよりは、「ちゃんと読ませて、先回りして動いてもらう」ほうが、トータルでは得になる、という結論になっています。
Claude Codeと長く付き合っていきたい人にとっては、運用ノウハウとしてかなり参考になりそうな記事でした。

。。，。

というわけで、きょうのzenncastは、
・余っているPCを活用した、自宅サーバーの楽しさと始め方の話、
・Claude Opusにサンゴ礁のピクセルアニメを丸ごと作らせた実験、
・確率付き判断に特化した新しいAIモデル「Jev」の紹介、
・AWS DevOps Agentのセキュリティ検証と、安全に使うための設計のポイント、
・Claude Codeの自動メモリを掃除して、`.claude/rules`でうまく運用するテクニック、

この五本を駆け足でお届けしました。

気になった記事やサービスがあれば、詳しくは番組のショーノートにタイトルを載せておきますので、あとでじっくり読んでみてください。
zenncastでは、番組の感想や、「こんなテーマを取り上げてほしい」といったリクエストも、いつでも募集しています。日々の開発の中で気になったこと、ちょっとした愚痴なんかも大歓迎です。

それでは、きょうも良い一日をお過ごしください。
お相手はマイクでした。また次回のzenncastでお会いしましょう。