どうもみなさんおはようございます、マイクです。
今日も「zenncast」のお時間がやってまいりました。
今日は二〇二六年九月二十日、日曜日の朝七時をちょっと回ったところです。
この番組では、毎回 Zenn に上がっているトレンドの記事の中から、開発者のみなさんに刺さりそうなネタを楽しく紹介していきます。
さてさて、きょうはお便り紹介はお休みで、そのぶんガッツリと記事を紹介していきたいと思います。
きょう取り上げる記事は全部で五本。AIの社内導入の工夫から、開発フロー、AWS Lambda の最新事情、Xcode の新しいプロジェクト形式、そしてローカル LLM を使ったコードレビューの話まで、盛りだくさんでお届けします。
まず一つ目は、社内でバラバラに使われていた ChatGPT や Claude といった AI ツールを、どうやってちゃんとコスト管理しながら一元化したのか、というお話です。
この会社では、最初はみんな好き勝手にいろんな AI サービスを使っていて、「コストがいくらかかってるのか分からない」「情報管理もバラバラ」という状態だったそうなんですね。そこで、社員全員が使う入り口を「OpenCode」というクライアントに統一して、その裏側に「LiteLLM」をゲートウェイとして置く、という構成に切り替えています。
LiteLLM が各社の LLM への入り口になっていて、社員ごとに発行したキーに「週単位の予算上限」を設定しておくことで、使いすぎを自動的に防げるようにしているんですね。さらに、「どのモデルをどれだけ使っているか」も、一か所でまとめて把握できるようになったと。
おもしろいのが、モデル名を社員からは「ロー」「ミッド」「ハイ」「エクストラハイ」みたいな社内向けラベルで見せていて、そのラベルの中身、つまり実際にどのモデルにつなぐかは LiteLLM 側で差し替えているところです。これによって、社員の設定をいじらなくても、裏で「コストと性能のバランス」をちょこちょこ調整し続けられるようになっています。
表のクライアントに選んだ OpenCode は、JSON の設定ファイルを配るだけで使えて、ワンライナーのスクリプトで非エンジニアにもサクッと配布できるところが決め手だったそうです。
さらに、外部サービスとの連携は Cloudflare の MCP ポータルに一本化していて、「AI に何かさせたいときは、とりあえずここ経由で」とルールを決めることで、情報の出口も整理していると。
その結果、AI 利用コストは導入前の「じゅうぶんのいち以下」まで下がったのに加えて、プロンプト内容や利用状況の可視化も一気に進んだ、というレポートになっています。社内で AI の導入がカオスになりつつあるチームには、かなり参考になる構成ですね。
。 。 。 。
続いて二つ目は、AI を使った開発フローの話。テーマは「人間の判断をどう AI に置き換えるか」です。
筆者が問題にしているのは、「AI は実装をすごいスピードで書けるのに、人間のレビュー待ちで結局ぜんぶ止まっている」という状態です。ここを解消するために、人間が関わる場面をぐっと絞って、「仕様を決めるとき」と「最終確認」のほぼ二か所に限定し、それ以外の工程は基本的に AI だけで回るように、開発フロー全体を組み直したという話になっています。
具体的には、要件分析、仕様設計、テスト設計、実装といった工程を、それぞれ役割ごとの「サブエージェント」に分けて、さらにそれらをまとめる「メインのエージェント」を一体置く構造です。
このメインエージェントが、「どの工程をいつ呼ぶか」「レビューの指摘が出たらどう扱うか」「どんな条件になったら処理を止めるか」といったことを、あらかじめ決めたルールにしたがって機械的に判断していきます。
ここで重要な役割を果たしているのが、一つのタスクごとに作る「仕様ドキュメント」です。
このドキュメントは、いわゆる設計書というよりは、「AI が判断するための材料」として位置づけられていて、特に「受け入れ条件」をはっきり書くことが強調されています。
テストで何を満たしていれば OK なのか、レビューでどこを見るべきなのか、基準をきちんと言語化しておくことで、テスト設計エージェントやレビュー担当エージェントが、同じ物差しでチェックできるようになるわけですね。
筆者が強調しているポイントは、「AI を魔法のように賢くすること」ではなくて、「いままで人間が暗黙にやっていた判断基準を、AI が機械的に使えるルールとして言語化すること」だ、というところです。
たとえば「このレベルの仕様のあいまいさなら進めていいのか」「このエラーは自動でリトライすべきか、一回人に聞くべきか」といった、普段なんとなくやっていた判断を、きちんと文章と条件にしておく。
これができていれば、AI 自体の賢さに頼り切らなくても、かなりの部分を自動化できる、というメッセージになっています。
。 。 。 。
三つ目の記事は、AWS Lambda の「九十分タイムアウト拡張」についての技術解説です。
いままで Lambda の一回の実行時間は、最長でも十五分まででした。ところが新しく、「Lambda Managed Instances」、略して LMI 上で動く関数に限って、しかも「非同期」か「イベントソースマッピング経由」の呼び出しであることを条件に、一回の実行がなんと九十分まで許されるようになりました。
これによって、「S三 にファイルが置かれたら、重い変換処理を一つの Lambda 関数の中で最後までやりきる」といったパターンが、いちいち Step Functions を挟まなくても、現実的な選択肢になってきたわけですね。
とはいえ、この LMI には注意点もいろいろあります。
まず、通常の「呼ばれたときだけ課金」の Lambda と違って、LMI は実体としては EC二 のインスタンスが裏で常時起動している形に近くなります。そのため、VPC や NAT の構成をちゃんと考える必要があるし、バージョンの運用も含めて、「呼ばれなければゼロ円」という世界観ではなくなってくるんですね。常時起動しているぶん、EC二 の料金もかかってきます。
この記事では、「durable functions」と組み合わせたときの話も出てきます。
durable functions 全体としての最長実行時間は、これまでどおり最長一年のままなんですが、その中で一つのステップとして連続で動かせる処理時間が、十五分から九十分に伸びることになります。
これによって、長時間かかるジョブをどう分割するか、どうリトライを設計するかといったアーキテクチャの自由度が、大きく広がると説明されています。
一方で、運用上の落とし穴にも注意が必要だという指摘もあります。
たとえば、SQS をイベントソースにしている場合は「可視性タイムアウト」をどれぐらいに設定するのか。非同期呼び出しのリトライまわりで、九十分動いたあとにエラーになったらどうなるのか。長時間のネットワーク接続が、途中で切断されてしまうケースはどう扱うのか。
こういった細かい部分をちゃんと設計しておかないと、「九十分動かせるから安心」と思っていたら、途中でタイムアウトにぶつかって予期せぬ再実行が起きる、といった事故につながりかねないので、そのあたりを実験結果とあわせて丁寧にまとめている、という内容になっています。
。 。 。 。
四つ目は、iOS や Mac の開発をしている方にはかなりホットな話題。Xcode 二十七点二以降で使える、新しいプロジェクト設定ファイル形式、「project.xcproj」についての記事です。
これまで Xcode のプロジェクト設定といえば、「project.pbxproj」というテキストファイルでしたが、あれ、ID だらけで読みづらいんですよね。ファイルをひとつ追加するだけで、離れた四か所ぐらいに差分が出て、どこが何の設定なのか分かりにくいし、Git のコンフリクトも起きやすい。
そこで新しく入ってきたのが、JSON ベースの「project.xcproj」です。正確には JSONファイブ というフォーマットで、コメントを書けたり末尾のカンマを許容してくれたりする、ちょっとゆるめの JSON になっています。
新形式では、ターゲットに所属しているかどうか、みたいな情報がファイル側に寄せられていて、全体としてのファイルサイズもかなり小さくなります。
とはいえ、ターゲットなど一部のところでは ID 自体はまだ残っていて、完全に人間フレンドリーな名前だけになった、というわけではありません。それでも、これまでみたいに「よく分からない ID を追いかけて、対応関係を頭の中で復元する」必要はかなり減っていて、何が書いてあるかはだいぶ読めるようになっています。
Git のコンフリクトという観点でいうと、同じリストの同じ位置に、別ブランチで要素を足した場合なんかは、当然ながら `.xcproj` でもコンフリクト自体は起きます。
ただ、そのときに ID の羅列ではなく、構造化された JSONファイブ として中身を読めるので、「ああ、このファイルがこっちのターゲットに追加されたんだな」とか、「この設定を変えたいんだな」といったのが、かなり分かりやすくなっている、というのがポイントですね。
変換の手順としては、`xcodebuild -convert-project xcproj/pbxproj` のコマンドで、旧形式から新形式、新形式から旧形式へ、どちらの方向にも変換できます。
さらに `xcodeproj` コマンドを使うと、設定やターゲット、グループの操作なんかもスクリプトからいじれるようになっています。ただし `.xcproj` はさっき言った通り JSONファイブ なので、スクリプトから読むときは、それに対応したパーサーを使う必要があります。
注意点としては、Xcode 二十七以降でないと新形式のプロジェクトは開けない、というところです。
ですので、チーム開発で使う場合は、CI サーバーや配布に使っている環境も含めて、Xcode のバージョンがちゃんとそろっているかどうか、それから `project.pbxproj` を直接読んでいる周辺ツールが、新形式に対応しているかどうかを事前に確認する必要があります。
筆者は、「まずは環境が整っている小さなプロジェクトから試してみて、移行プルリクには、使った Xcode のバージョンや検証内容、もし元に戻すときの手順も、しっかり明記しておくといいですよ」と勧めていました。安全に新形式へ移行するための、実務的なノウハウが詰まった記事になっています。
。 。 。 。
そして最後、五つ目は「クラウド LLM のトークンを節約するために、ローカル LLM をコードレビュー専用に使う工夫」を紹介した記事です。
舞台になっているのは、十七万行クラスの大きなプロダクト。ここでは、AI が生成したコードの「全部」を人間がレビューするのは、現実的じゃないレベルのボリュームになってしまっています。
しかも、レビューのたびにクラウド LLM に投げていると、それだけでトークンを大量消費してしまう。コスト的にも、待ち時間的にも、これはつらいよね、という問題意識があるわけですね。
そこで著者がとったアプローチが、「ローカルで動かす LLM を、コードレビュー専用のフィルタとして育てる」というものです。
具体的には、手元の GPU、RTX さんぜろろくぜろを使って、「qwen にてんご・コーダー・じゅうよんビー」というモデルを Ollama で動かしています。
このモデルに対して、「git diff を渡したら、重大なバグ候補だけを JSON で返してくれるローカル専用レビューモデル」という役割を与えているんですね。
システムプロンプトの中で、かなり細かくルールを指定しているのがポイントです。
たとえば、「対象とする技術スタックはこれこれです」とか、「検出してほしいリスクは、データ損失やクラッシュ、セキュリティ境界の破壊などです」といった、見てほしいポイントをしっかり言語化する。
同時に、「コードスタイルの好みレベルの話は無視して」「命名やインデントだけの指摘はいらないです」といった「無視すべき指摘」も明示しておきます。
出力形式も、JSON の配列だけにきっちり制限しておくことで、自分がやっている Issue ドリブンな開発フローの中に、そのまま組み込みやすくしているんですね。
性能としては、さすがにクラウドの巨大モデルと比べると、まだそこまで賢くはないと正直に書かれています。
それでも、「これはちょっとヤバそうだぞ」という変更を一次フィルタとして拾い上げる役割なら、十分に機能していると。
これによって、「実装の相談」や「高度な設計レビュー」はクラウド LLM に集中させて、日常的な粗探し、ざっくりした危険検知はローカル LLM に任せる、という役割分担がうまくいっていると述べています。
クラウドのコストが気になっているチームや、「全部を大モデルに投げるのはちょっと…」と思っている方には、かなり現実的なヒントになりそうです。
。 。 。 。
というわけで、きょうの「zenncast」は、全部で五本の記事をご紹介しました。
振り返ると、まず最初は、社内の AI ツール利用を OpenCode と LiteLLM で一本化して、コストも情報管理も整えた事例。
二本目は、人間が暗黙でやっていた判断基準をルールとして言語化して、AI 中心の開発フローに組み替えた、というオピニオン記事。
三本目は、Lambda の九十分タイムアウト拡張で、長時間ジョブの設計自由度が上がる一方、運用の落とし穴にも気をつけよう、という技術解説。
四本目は、Xcode の新プロジェクト形式 `project.xcproj` で、JSONファイブ ベースの、コンフリクトに強くて読みやすい設定ファイルが使えるようになった話。
そして最後は、ローカル LLM を「ヤバい変更の一次フィルタ」にして、クラウド LLM のトークンを節約しながらコードレビューに活用していく工夫、というラインナップでお届けしました。
気になる記事があったら、このあとショーノートに詳しい情報を載せておきますので、ぜひ元の記事も読んでみてください。
番組への感想や、「こんなテーマも取り上げてほしい」といったリクエストも、いつでも大歓迎です。あなたの現場での工夫や悩みなんかも、ぜひ教えてください。
それでは、きょうも一日、いいコードといい発見がありますように。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。