どうもー、おはようございます。マイクです。
zenncast、七月二十六日、日曜日の朝七時を回りました。
この番組では、技術系のナレッジ共有サービス「Zenn」に投稿された、旬なトレンド記事をゆるっと、でも中身はみっちりお届けしていきます。
今日はお便り紹介はお休みしまして、そのぶん記事をじっくりとご紹介していきますね。
きょうピックアップする記事は、全部で五本です。インフラ運用の落とし穴、クラスタ侵害のリアルな事例、自宅サーバーの作り方、ローカルで動かすAIモデルの実験レポート、そして超小型ローカルLLMのTIPSまで、盛りだくさんでいきます。
それでは、今日紹介する内容に入っていきましょう。
まず一つ目。
一つ目は、TerraformとかKubernetes周りの、いかにも現場でハマりがちな「よくある落とし穴」を体系的にまとめてくれている記事です。
大前提として、Terraformって、プランが通ったからといって安心できないよね、という話から入っています。`terraform plan` が通っても、実際に `apply` してみたら、クラウドのAPI制約でエラーになったり、事前に有効化しておくべきサービスがオフのままだったり、起動したVMにログインできなくて詰んだりと、「動かしてみて初めて分かる失敗」がとにかく多い。なので、計画だけで満足せず、ちゃんと `apply` して挙動を確かめることが重要だと。
新しいモジュールを書くときによく抜ける「四点セット」というのも挙げられていて、それが、バージョン管理用の `versions.tf` によるプロバイダ宣言、変数に対する validation の定義、`terraform fmt` でのコード整形、それから lockファイルの扱い。この四つは、モジュール作り慣れてないとほんとに抜けがちなので、「自分のPRを出す前に、この四点ちゃんと入ってる？」ってセルフチェックしておくといいよ、という話が出てきます。
あとは、リージョンとかクラスタ名みたいに、環境ごとに変わりがちな値をソースコードに直書きしてしまうパターン。これをやると後から環境増やしたときに毎回差分が増えてつらいので、素直に変数化しておきましょうと。
Terraform特有の罠としては、`enabled = false` にしてリソースをオフにしたつもりが、裏で `count` がゼロのリソースにインデックスアクセスしてしまって、planそのものがクラッシュする、みたいなパターンも紹介されています。これも、三項演算子でガードを入れるとか、`enabled` をちゃんと考慮して参照することで防げるよ、という具体的な書き方の話が出てきます。
IAMまわりでは、権限不足で実行時に `AccessDenied` が出るパターンと、逆に `Resource="*"` のように権限を盛りすぎてしまうパターンの両方があるよね、と。どちらもレビューでよく突っ込まれるところで、「まず、そのワークロードが実際に呼びうるAPIをちゃんと列挙しよう。そのうえで、最小限の権限を設計しよう」という、割と本質的な指針が強調されています。
TLS周りも、「暗号化オンにしたから安心」じゃないよ、という指摘。たとえばPostgreSQLだと、`sslmode` を単に `require` にしているだけだと、中間者攻撃を完全には防げないので、`verify-ca` のようにサーバ証明書の検証まで有効にして、ちゃんと組織のセキュリティポリシーと合わせようね、という話が出ています。
Kubernetesでは、NetworkPolicyが静かに通信を落としてしまう罠。Pod間の通信やDNSの名前解決がポリシーで遮断されてるのに、エラーが分かりづらくて「なんかつながらないな……」で時間を溶かすパターン。さらにHelmだと、`values.yaml` のキー階層を間違えていたり、ラベルが不一致だったりすると、nodeAffinityとか重要な設定が「エラーにもならず、きれいさっぱり無視される」という怖い挙動があります。これを避けるために、`helm template` で一回レンダリング結果を確認しよう、と具体的なワークフローが提案されています。
そして最後に、コード以外の「説明」がずれる問題。マージリクエストの説明と実際のdiffが合っていなかったり、コメントやREADMEの内容が現状と食い違っていたり、「まだマージしてない前提」で書いた手順書が、そのまま放置されていたり。こういうのもレビューでかなり突っ込まれるので、「このMRがマージされたあとに、説明・コメント・READMEがすべて真実になるか？」をセルフチェックしよう、と締めくくられています。
インフラやSRE、Terraform触ってる人には刺さる「あるある」がぎゅっと詰まった記事でした。
。。.。。.。..
続いて二つ目。
これは、ちょっと怖い話です。放置していた旧Kubernetesクラスタ上のNext.jsアプリが、「React Server Components」の脆弱性、いわゆる React2Shell を経由して実際に侵害されてしまった事例を、かなり詳しく分析した記事です。
被害の流れとしては、まずReact2Shell形式のPOSTリクエストを受けた直後に、`next-server` 配下で不審なシェルが起動していました。そこから `/tmp` や `/dev/shm` にELFバイナリをダウンロードして実行していたことがログから分かったと。
そこから先の挙動がまたいやらしくて、単一の攻撃者じゃなくて、複数の攻撃者がそれぞれ別の目的で入り込んでいる形跡があったそうです。
具体的には、CPUを使い潰すようなプログラムを動かしていたり、「TraffMonetizer」というサービスを使って、勝手に回線を「副業利用」するようなことをしていたりします。さらに、Global Socketやリバースシェルを使って遠隔操作できるようにしたり、クラウドのメタデータサービスにアクセスを試みるなど、かなり多様な悪用が同時並行で走っていたとのこと。
幸いだったのは、このPodが特権コンテナではなく、ネットワーク的にもある程度分離されていたので、ホストマシンへの脱出までは至らなかった点です。ただし、外向きの通信が制限されていなかったことと、CPUなどのリソース制限が甘かったことで、攻撃者たちに好き放題使われてしまった、と。
筆者は、「一番の原因は、使っていない公開環境をそのままインターネットに晒し続けていたことだ」と振り返っています。そのうえで、対策としてかなり具体的な提案を挙げています。
たとえば、インターネットに出ている公開資産の棚卸しと、使っていない環境の早期停止。パッチはできるだけ早く当てること。コンテナに付与する権限と、書き込み可能なディレクトリを最小限に絞ること。外向きの通信を制限し、クラウドのメタデータサービスへのアクセスも遮断すること。ServiceAccountとRBACは最小権限にし、CPU・メモリ・PIDなどのリソース制限もちゃんと入れる。
さらに、メトリクスやランタイム検知、ログによる監視をしっかり行い、もし侵害が疑われたら、隔離してからクリーンな環境を再構築すること。そして、漏えいの可能性があるSecretはローテーションするといった、インシデントレスポンスの流れも具体的に書かれています。
印象的だったのは、「自宅サーバーだから、まあ大丈夫でしょ」ではなくて、自宅だろうが企業だろうが、インターネットに出ている限りは誰かを攻撃する踏み台になり得る、という指摘です。なので、古くなった環境の棚卸しと停止は、趣味サーバーでも徹底しよう、と締められていました。
「なんとなく残してる昔のクラスタあるな……」という方には、かなり刺さる内容だと思います。
。。.。。.。..
三つ目の記事にいきましょう。
三つ目は、自宅に検証用とか開発用のサーバーを、できるだけ安く、それでいてそこそこ高性能に作る方法を紹介した記事です。
筆者が実際に組んだ構成としては、メモリ三十二ギガバイト、SSD一テラバイト、CPUがRyzenファイブ五六〇〇ジーティー、ベアボーンにDeskMeet X三百、OSはUbuntuという組み合わせ。これで、予算十万円以内に収めつつ、開発用にはかなり快適なマシンになったよ、という実例が紹介されています。
コストを抑えるコツとしては、「全部を新品・最新にしない」という割り切り方がポイントになっていて、SSDは信頼性のために新品を選ぶ一方、メモリは中古をうまく活用する。CPUやSSDも、最新世代じゃなくて、一世代古い規格を選ぶことで、性能と価格のバランスを取る。さらに、秋葉原のTSUKUMOとかパソコン工房のセール品や中古コーナーをうまく使うと、かなりお得に組めるよ、という、かなり生々しい買い物テクニックが紹介されています。
組み立てたあとは、UbuntuをUSBメモリからインストールしていきます。このとき、ルートパーティションの容量を最大まで割り当てておくことと、インストール時のオプションでOpenSSHサーバーにチェックを入れておく。そうすると、最初からSSHで入りやすい「開発サーバーっぽい」構成になります。
その後、LANケーブルで自宅のWi‑Fiルーターと同じネットワークに接続して、自分のPCから `ssh` や `ping` で疎通確認をする、という手順も丁寧に書かれています。
さらに、家の外からもこの自宅サーバーにアクセスしたい場合の方法として、Tailscaleを使う手段が紹介されています。Tailscaleを、自宅サーバーと自分のノートPCやスマホなど各端末にインストールして、GitHubアカウントでログインしてネットワークに参加。自宅サーバー側では、`sudo tailscale up --ssh` のようなコマンドで設定しておくと、あとは `ssh ユーザー名@デバイス名` みたいな形で、安全にリモート接続できるようになると説明されています。
クラウドと比べたときのメリットも整理されていて、たとえばGCPみたいなクラウドを常時起動で使っていると、月に数千円から、一万円くらいまでは普通にかかってしまう。一方で、自宅サーバーは一度組んでしまえば、画像の保存場所にしたり、個人開発用の常時起動サーバーにしたりと、長く使いまわせる。
その結果、「クラウドの利用料金を抑えつつ、自分好みに環境をカスタマイズできる」のが大きな魅力だ、とまとめられています。
「クラウドの検証環境、毎月ちょっともったいないなあ」と思っている方には、背中を押してくれる記事だと思います。
。。.。。.。..
四つ目の記事です。
ここからはAIの話題。Moonshot AI が出しているコード特化モデル「Kimi Kツー・セブン Code」を、なんとMac Studio一台だけでベンチマークに走らせた、実験レポートと所感をまとめた記事です。
筆者は、Kimi Kツー・セブン Codeの「二ビット量子化版」をローカル環境で動かして、SWE-Lancerという、ソフトウェアエンジニア向けの難しめのタスク群に挑戦させています。
その中でも、特に難易度が高い「IC SWE ダイヤモンド」と呼ばれる一九八タスクのセットを選び、十三日間かけて連続実行する、というなかなかストイックな実験をしています。
最初は、標準のソルバーをそのまま使っていたのですが、ここで問題が発生します。モデル側が「Pythonのツール呼び出し」を前提に振る舞うように設計されているのに、ソルバーがそれをうまく扱えていなかったため、正解率が三・八五パーセントという、かなり悲惨な結果になってしまったんですね。
そこで筆者は、思い切ってソルバーを実装し直します。ツール呼び出し前提の、新しいソルバーを作り、さらに、モデルの出力が崩れてツールの結果がきれいに取れなかった場合でも、コードの部分を拾い直して評価し直す、というリカバリ処理も加えています。
その改善の結果、Mac Studio一台、二ビット量子化、完全ローカル実行という条件ながら、IC SWE ダイヤモンドで四七・ゼロパーセントの正解率を達成します。
ベンチマーク上では、それを想定報酬に換算すると、「二週間弱で六万九千八百七十五ドル、つまり全体報酬の三六・九パーセントを稼いだとみなせる」スコアになった、というのが非常にインパクトのあるポイントとして紹介されています。
とはいえ、高額案件ほど取りこぼしが多い傾向が見えたり、一応の安全策として「一回の応答に九百秒」という時間制限を独自に設けていたため、それがなければもっとスコアが伸びていた可能性もある、と自己分析しています。
それでも、たった一年前には、クラウド上の最強クラスのモデルでも、このベンチマークで二六・二パーセントくらいが限界だったことを考えると、「家庭用マシン一台でここまで来たのか」という進歩の速さに、かなり驚かされます。
この記事は、単なるスコア自慢というより、「ローカル環境でモデルを動かすときに、どうツール呼び出しを組み合わせるか」「どこでボトルネックが出るか」といった実務的な視点も交えて書かれていて、AIエージェントや自動コーディングに興味がある人には読み応えのある内容になっています。
。。.。。.。..
最後、五つ目の記事です。
こちらは、ローカルLLMの中でも「Bonsai」という、ちょっと変わり種のモデルを紹介するTIPS系の記事です。
Bonsaiは、重みを最初から一ビット、つまりプラスワンかマイナスワンだけで学習するという、かなり攻めた設計のモデルなんですが、それでも精度が高い、というのが売りになっています。いわゆる「超小型なのに賢いローカルLLM」ですね。
たとえば八ビリオン規模のモデルでも、ファイルサイズが約一・一五ギガバイトで、必要なメモリも一・五ギガバイト程度。これなら、GPUのない普通のPCでも現実的な速度で動かせる、というのがポイントです。
ただし、通常のllama.cppやOllamaでは、Bonsaiはそのまま動きません。なので、PrismML公式の「Bonsai-demo」を使うか、PrismMLがメンテナンスしているllama.cppのフォーク版を使ってセットアップする必要があります。
起動するときは、`start_llama_server.sh` というスクリプトでサーバーを立ち上げる形になっていて、このサーバーがOpenAI互換のAPIを提供してくれます。つまり、既存のOpenAI用のコードは、そのまま使って、ベースURLだけBonsaiのサーバーに差し替えてあげれば、アプリ側の変更は最小限で済むよ、という便利な設計になっています。
使いどころとしては、八ビリオンのモデルは、ローカルチャットとか要約、文書処理、社内ツールの自動タグ付けといった、「一件あたりは軽いけどリクエスト頻度が高いタスク」を、クラウドに投げずに安く回したいときに向いている、と紹介されています。
一方で二十七ビリオンのモデルになると、画像入力や関数呼び出し、いわゆるツール呼び出し、それから長文コンテキストにも対応していて、ノートPCレベルのメモリでも、「ローカルで完結する小さなエージェント」を構成できるポテンシャルがあると説明されています。
ただし、Claude CodeとかAiderみたいな、既存のコーディングエージェントの頭脳としてBonsaiを使おうとすると、現状では速度と能力の両面で、まだ少し厳しいところがあると正直に書かれています。今のところは、「エージェント経由でがっつり開発を任せる」というよりも、アプリケーションから直接BonsaiのAPIを叩いて、特定のタスクをこなさせる、という使い方のほうが現実的だろう、と。
そして最後に、「一・五八ビット」のTernary Bonsaiというバリエーションも紹介されています。これは、ビット数をちょっと増やす代わりに品質を上げたモデルで、エッジデバイス向けの、より現実的な選択肢とされています。
八ギガバイトメモリのPCとか、スマホのような端末でも動かしやすくて、「クラウドに依存せずにAIを手元で動かしたい」というニーズには、こちらがかなり有望なんじゃないか、というまとめでした。
ローカルLLM好きな方にはたまらないTIPSですね。
。。.。。.。..
というわけで、きょうのzenncastは、このあたりでお別れの時間です。
ざっとおさらいすると、まずTerraformやKubernetes運用の「あるある落とし穴」とセルフチェックのコツを紹介する記事。
次に、React Server Componentsの脆弱性Reactツーシェル経由で、放置クラスタが実際に侵害された事例と、その具体的な対策。
三つ目は、十万円以内で組む、自宅向けの高性能開発サーバーの作り方と、Tailscaleを使ったおうちVPN。
四つ目は、Kimi Kツー・セブン CodeをMac Studio一台でSWE-Lancerに走らせた、ローカルAIの実験レポート。
そして最後は、Bonsaiという超小型ローカルLLMの特徴と、実用的な使い方のTIPSを紹介しました。
気になった記事があったら、ぜひショーノートから元の記事もチェックして、細かいところまで読んでみてください。ここでは話しきれていないテクニックやコード例なんかも、たくさん載っています。
この番組zenncastでは、みなさんからの感想や、「こんなテーマ取り上げてほしい」といったリクエストもお待ちしています。普段聞いていて思ったことや、ご自身の開発ネタなんかも、ぜひ気軽に送ってください。
それでは、今日も一日、楽しく、そして安全に開発していきましょう。
お相手はマイクでした。また次回のzenncastでお会いしましょう。バイバイ。