どうも、マイクです。おはようございます。
二千二十六年八月二十八日、金曜日の朝七時をまわりました。
ここからの時間は「zenncast」、きょうも最新のZennトレンド記事を、ゆるっと楽しく紹介していきます。
さてさて、きょうは特にお便りは届いていないようなので、そのぶんガッツリ技術ネタいってみましょう。
きょう紹介する記事は、ぜんぶで五本。どれも実践で役に立つTips系やツール紹介が中心です。
まず一つ目。
一つ目は、Qwenスリーポイントエイト・フラッシュ・ネクストっていう、百二十五ビリオン規模のMoEモデルを、自作環境で本気チューニングした検証レポートです。
マシン構成は、RTXファイブオーナインゼロ、三十二ギガのVRAM、それからメモリ百二十八ギガの一台構成。これに、llamaドットcppと、UnslothのUDキュー・ツー・ケー・エックスエルという量子化を組み合わせて、なんと六万四千トークンのコンテキストで、デコード速度が一秒あたり四十三から四十八トークン、っていうかなり攻めた数値を出しています。
やっていることもけっこう細かくて、まずはQwenスリーポイントエイト・フラッシュ・ネクスト対応の、特定のコミットのllamaドットcppを自前ビルド。CUDAを有効化して、RTXファイブオーナインゼロをフルに回せるようにしています。
そのうえで、一番効いたのが「マイナス・エヌ・シー・エム・オー・イー」っていうオプションの調整。これは、どれくらいのMoEエキスパートをGPU側に載せるか、っていう指定なんですけど、VRAMが許すギリギリまでエキスパートをGPUに乗せることで、デコードもプリフィルもガツンとスピードアップしたそうです。
CPU側のチューニングもあって、スレッド数は物理コア数と同じ「八」が最適だったとのこと。さらに、スレッドをコアゼロからセブンに固定して動かすと、平均速度自体は変わらないのに、実行ごとのばらつきがかなり減って、安定したスループットが出せたと。
逆に、マイクロバッチサイズを減らしたり、四種類のエヌグラム投機デコードを試したりもしているんですが、プリフィルや初回トークンまでの時間が悪化したり、メモリアクセスが増えたりして、トータルの性能はむしろ悪くなったので、最終的には採用を見送った、という結論になっています。
ローカルで巨大モデルを本気で回したい人には、かなり生々しい知見が詰まった記事ですね。
。。，。。
続いて二つ目。
二つ目は、TerraformでAWSインフラを管理するときに使える、ローカルAWSエミュレータの検証記事です。とくにFlociというツールにフォーカスしたTips系の内容ですね。
FlociとかLocalStack、それからmotoみたいなエミュレータを使うと、実際のAWSアカウントがなくても、TerraformやAWS CLIを相手に、そこそこ本番ライクな検証ができる、というお話です。
その中でもFlociは、オープンソースで登録も不要、しかもRDS相当まで無料で試せるのが特徴になっています。
Terraform側の設定としては、AWSプロバイダで`endpoints`を設定したり、環境変数を使ったりして、たとえば「ローカルホストの四五六六番ポート」に向けるイメージです。合わせて、資格情報のチェックとか、アカウントIDの取得はオフにしておく、と。
ただし、Flociが全部を再現してくれるわけではなくて、API経由の設定情報の読み書き、いわゆる「コントロールプレーン」はかなり似せてくれる一方で、セキュリティグループやルートテーブルによる通信制御、それからRDSの「SSL必須」のような実際の通信まわりは、かなり簡略化されています。
RDSに関しては、実際のMySQLやPostgreSQLコンテナを使っているので、SQLの動き自体は確かめられるんですが、ネットワークレベルの挙動までは追えない、という感じですね。
具体的な検証だと、データベースのホスト名やポート番号の間違い、Terraformの循環参照みたいな「Terraformレベルの依存関係の不整合」、それから単純な接続ミスなんかは、ローカルエミュレータでもちゃんと検出できたそうです。
一方で、セキュリティグループの設定ミス、ルートテーブルのルート漏れ、RDS側でSSL必須になっているケース、IAMロールが足りないといった問題は、ほとんど検証できなかったと。
TrivyやCheckovみたいな静的解析ツールも試していて、デフォルトルールだけだと設定ミスの検出はほぼできず、「このセキュリティグループは三三〇六番ポートを開けるべき」みたいに、けっこう細かいカスタムルールを書いていかないと、実務レベルでは厳しいという話も出てきます。
Terraformの循環参照については、やっぱり「terraform validate」が一番ちゃんと捕まえてくれる、という評価でした。
さらに、FlociをECSとRDSの組み合わせで使うときには、ネットワーク周りの工夫も必要で、Flociとアプリケーションコンテナを同じDockerネットワーク上に置いて、「FLOCI_HOSTNAME」を指定してあげる。ホストマシンからアプリにアクセスしたい場合は、「socat」などでポートを中継してあげる、といった手順が紹介されています。
また、Flociはリソース状態を完全には保持しないので、「apply」した直後でも、「plan」に毎回差分が出ることがあるそうです。なので、「planが本当にノーオペレーションかどうか」の確認用途にはあまり向かない。
結論としては、ローカルエミュレータだけに頼るのではなくて、実際のAWSサンドボックス環境と組み合わせて使うのが現実的、という落としどころになっています。
。。，。。
三つ目の記事。
こちらは「Orca」というAgent IDEの紹介で、「複数タスクの並行開発に本気で向き合ったエディタ」といった内容です。四つ以上のセッションを同時に扱うような状況でこそ、本領を発揮するツール、という位置づけですね。
一番の特徴は内蔵ブラウザで、セッションごとにブラウザのタブ群もセットで切り替わる、という仕組みになっています。
たとえば、あるセッションではGitHubのプルリクエストと、動作確認用のアプリ画面、そしてSlackのスレッドとスプレッドシートを開いている。別のセッションでは、別プロジェクトのPRとドキュメントを開いている。
こういうときに、普通のブラウザだとタブ地獄になりがちなんですが、Orcaだと、その「タブの束」がまるごとセッションの一部になっていて、セッションを切り替えるだけで、関連するタブ群がガサっとまるごと切り替わる。
この「重たいブラウザ側の文脈を一括で切り替えられる」のが、とにかく気持ちいいというわけですね。
既存のツールで不便だった、「タブが一枚しかなくて足りない」とか、「パスキーに対応していないからログインできない」とか、「スーパーリロードがやりづらい」といったポイントも、ほぼ解消されていて、普段のブラウザにかなり近い感覚で使えるところも評価されています。
さらに、モバイル版でもデスクトップとほぼ同じユーザーインターフェースで使えるので、席を離れても、そのまま作業を引き継ぎやすい、というのも嬉しいところです。
それ以外にも、デフォルトブランチの自動同期、AIが勝手に作ったワークツリーを一覧から隠す機能、それからサブエージェントを可視化する機能など、「並行開発中にじわじわストレスになりがちな小さな不満」を、かなり丁寧につぶしているのが印象的だと紹介されています。
いろんなプロジェクトを同時に回しているエンジニアには、刺さるツールかもしれません。
。。，。。
四つ目。
四つ目は、AWS Secrets Managerでシークレットをどう分けるか、その設計指針を整理した記事です。
ポイントは、「用途」と「更新タイミング」、つまりライフサイクルが同じものを一単位にまとめるべき、という考え方ですね。
公式ドキュメントを読んでいくと、「最小権限の原則」と「定期的なローテーションが推奨されている」という二つのメッセージが出てきます。そこから、「用途やライフサイクルが異なる秘密情報を、一つのシークレットにギュッと詰め込むのはよくないよね」という結論になっています。
たとえば、データベースの接続情報一式とか、特定の外部APIを呼ぶために必要なキー一式、こういった「一つの機能を動かすために必要なセット」を、一シークレットにまとめるのが自然な粒度だろう、というわけです。
逆に、データベースの接続情報と、まったく別の外部APIキーを同じシークレットに入れてしまうと、本当はDB情報だけ読めればいいロールが、余計なAPIキーまで読めてしまったりして、最小権限にならない。
さらに、Secrets ManagerはJSON全体を一つのバージョンとして管理する仕組みなので、Terraformで見ると差分の中身が「センシティブ・バリュー」としてマスクされてしまい、「どのフィールドが変わったのか」が分からなくなります。
一つのシークレットにたくさん情報を詰め込みすぎると、「何が変わったのか」が見えづらくなって、設定ずれに気づきにくくなる。
とくにTerraformでインフラをコード管理しているケースでは、適切な粒度でシークレットを分けておくことが、本当に大事ですよ、というメッセージになっています。
。。，。。
そして最後、五つ目の記事。
こちらは、GitHub Enterprise環境でCopilotをどう統制するか、その方法を整理したTips系の記事です。Enterprise管理者目線の、かなり実務寄りのまとめになっています。
まず出てくるのが「AI Controls」。
これは、「Copilotや各種エージェントをそもそも使わせるかどうか」を決める、大枠のスイッチみたいなものです。
全社単位でオンオフしたり、特定のオーガニゼーションだけ有効にしたり、オーガニゼーションごとの判断に任せたり、あるいは全部無効にしたりといった単位でコントロールできます。
制御対象としては、Cloud AgentやCode Reviewといった各種エージェント、Copilotが使うモデルの種類、それからMCPサーバーの利用可否などが含まれています。
次に出てくるのが、「Enterprise managed settings」。
これは、リポジトリの「ドットgithub・プライベート・スラッシュ・copilot・スラッシュ・マネージド・セッティングス・ドットジェイソン」というファイルで細かい挙動を決められる仕組みで、「どこまで安全にCopilotを使わせるか」をかなり厳密にコントロールできます。
具体的には、権限確認のバイパスを禁止したり、MCPサーバーごとに許可・拒否を設定したり、サンドボックスの動きを決めたり、といったことができます。
さらに、プラグインや社内マーケットプレイスの制御、OpenTelemetryを使った利用状況の収集、リモート操作を許可するかどうか、こういったところまで設定可能です。
MCPサーバーについては、「許可リスト」と「拒否リスト」の二段構えで制御できて、拒否リストのルールが常に優先されます。
allowedMcpServersを空の配列にしておくと、組み込みのもの以外のMCPを一括で拒否する、といった運用もできます。
Copilot CLI向けのサンドボックス機能も取り上げられていて、どんなコマンドを実行していいか、どのファイルやディレクトリにアクセスできるか、ネットワークや認証情報にどこまで触っていいか、かなり細かく制限できると説明されています。
しかも、MDMツールからの設定や、サーバー側の設定など、複数の設定元がある場合は、「一番厳しい制約が合成される」ようになっているので、安全側に倒れやすい設計になっていると。
さらに、Enterpriseのチーム単位でも、モデルの種類やバイパス禁止設定、MCPの許可・拒否などを上書きしたり、追加したりできます。これによって、チームごとにセキュリティレベルを変える、という運用が可能です。
記事の中では、「社内プラグイン用のマーケットプレイスを作って、全社で有効化する」といった具体例も紹介されていて、Copilotを単に解禁するだけじゃなくて、「どう安全に活用していくか」を設計するうえでのヒントが詰まった内容になっています。
。。，。。
というわけで、きょうのzenncastは、
ローカル一台で巨大MoEモデルをブン回した高速化レポート、
TerraformとFlociなどのAWSローカルエミュレータ活用のコツと限界、
並行開発に特化したAgent IDE「Orca」の魅力、
Secrets Managerのシークレットを「用途とライフサイクル」でちゃんと分ける話、
そしてGitHub EnterpriseでCopilotをきっちり統制するための設定方法、
この五本を駆け足でお届けしました。
気になった記事の詳しい内容や、いま話したキーワードなんかは、ショーノートにまとめておきますので、あとでじっくりチェックしてみてください。
番組の感想や、「こんなテーマを取り上げてほしい」といったリクエストも、いつでもお待ちしています。
それでは、きょうも良い一日を。
お相手はマイクでした。また次回のzenncastでお会いしましょう。