ブログ

プロジェクトの設計文書が増えてきて、AIコーディングエージェントに「関連文書を読んでから作業して」と言う回数も増えてきた。エージェントへの指示書（AGENTS.md）は膨らみ続け、会話が長くなると、AIは序盤に伝えたはずのルールを忘れる。それなら、文書をAIに検索させる仕組みを作ればいい——社内RAGを検討した動機がこれだ、という方には共感いただけるのではないかと思う。

当社もまさにそれで、2026年6月の初めに、設計文書を検索するための社内RAGを作った。そして7月31日に、全面的に廃止した。精度が低かったわけでも、費用がかさんだわけでもない。索引（index）の鮮度を、安全に、安く保証する方法が見つからなかったからである。

「社内の文書をRAGで検索できるようにする」は、生成AIの業務活用で最初に出てくる定番の企画だと思う。当社はその定番どおりに作り、定番には書かれていない理由で止めた。本稿はその2か月の記録である。先に言っておくと、これは「RAGは使えない」という話ではない。「動くRAG」と「信じてよいRAG」のあいだにある距離の話だ。

前提 — どんな現場の話か

EastCloudでは、デジタル庁がOSSとして公開した政府向け生成AI「源内」を、国産のさくらのクラウド上で動かせるかを検証するプロジェクトを進めている（経緯は1本目の記事にまとめた。未読の方はそちらから）。このプロジェクトは、AIコーディングエージェントが実装・レビュー・監査の実作業の多くを担い、人間は方針と判断に集中する体制で動いている。

当時、エージェントの頭脳として使っていたモデルはGPT-5.5である。いまとなっては一世代前のモデルで、使い込むほどに困りごとがはっきりしてきた。まず、ルールや設計上の決まりはAGENTS.mdに書けば制御できるのだが、大規模なプロジェクトではそのAGENTS.md自体が肥大化していく。次に、会話が長くなると、序盤に渡したはずのルールが忘れ去られる。入力が長くなるほどモデルの性能が落ちるこの現象は、のちにChromaが「Context Rot」という名前で体系的に測定しているが、体感としては当時から明確にあった。そして、毎回「この文書とこの文書を読んでから始めて」と人間が指定する運用は、文書が数十本を超えたあたりで限界が来る。

そこで、AIが作業前に関連文書を自分で探すための検索RAGを、社内ツールとして試作した。なお本稿で扱うのはこの開発チーム内部の道具の話であり、製品にRAG機能を組み込む話とは分けて読んでほしい。

何を作ったか

構成は、いま社内RAGを作ろうとしている人が思い浮かべるものとほぼ同じだと思う。

• 対象: 設計の正本文書（要件、アーキテクチャ、ADR、ロードマップ、引き継ぎ文書、段階ごとの報告書）。作業ログや議事録、ソースコードは対象外
• 処理: 文書を見出し単位の塊に分け、軽量な多言語embeddingモデル（MiniLM系、384次元）でベクトル化し、ローカルで動くベクトルDB（Qdrantのローカルモード）に索引として保存
• 使い方: AIエージェントが作業前にコマンドで検索し、ヒットした文書の原文を読みに行く。検索結果は「ヒント」であって正本ではない、というルール付き
• 規模: 7月中旬の時点で78ファイル、約1,360チャンク

ツール自体は小さなPythonスクリプトで、作るのに大した時間はかからなかった。問題はそこではない。

あわせて、AIエージェント向けの作業ルールにこう書いた。「設計文書を追加・更新したときは索引を更新すること。検索結果を判断の根拠に使う前に、関係する文書の更新後に索引が再構築されたことを確認すること」。ルールとしては正しい。だが、このルールを守り続けることのコストを、当時は見積もれていなかった。

最初はうまくいった

7月初旬の段階では、ちゃんと役に立っていた。効果を実感した順に挙げる。

一番効いたのは、ルール逸脱が減ったことである。前述のとおり、当時のGPT-5.5は会話が進むとAGENTS.mdやコンテキスト上の指示が薄れ、序盤に決めたルールを踏み外すことがあった。作業の前にRAGで該当ルールと関連する設計判断を引き当て、原文を読み直させる運用にしてから、この「ルール忘れ」は目に見えて減った。長大な指示書を最初に一度読ませるより、いま必要な数枚をその都度引かせるほうが、明らかに効いた。

「どの文書に書いてあるか」を探す往復も減った。人間がパスを思い出して指定する代わりに、AIが自分で当たりをつけて原文へ到達する。新しいAIコンテキストを立ち上げるときのキャッチアップも短くなった。

編集する人が実質1人（動かすAIのコンテキストも1つ）だったあいだは、「更新したら再構築」の運用で十分に維持できた。文書の数が少ないうちは、索引の鮮度は問題にすらならなかったのである。

何が詰んだか

崩れ始めたのは7月中旬から下旬にかけてで、原因は3つ重なっている。

1つ目は更新の頻度である。 設計文書は、7月14日の67ファイルから7月29日の84ファイルへ、2週間で2割以上増えた。数が増えただけでなく、同じ文書が1日に何度も更新される。技術選定が進む時期は、ロードマップ、選定の台帳、ADR、引き継ぎ文書が連鎖して変わるからだ。「更新したら再構築」は、更新のたびに再構築が必要だという意味であり、更新が1日数回あれば、再構築も1日数回になる。そして再構築は、実行して終わりではない。検証まで含めた更新一式に30分ほどかかることもあった。1日に何度も行えば、それだけで明確なタイムロスである。

2つ目は並行開発である。 7月中旬以降、複数のAIコンテキストが別々のgit worktree（同じリポジトリの作業コピーを複数並べる仕組み）で並行して動くようになった。データ層の選定を進めるコンテキスト、認証まわりの検証を進めるコンテキスト、全体を束ねるコンテキスト。それぞれの作業コピーでは、文書の状態が違う。未コミットの変更もある。ところが索引は1つしかない。「この索引は、どの作業コピーの、どの時点の文書を写したものか」が、もう説明できなくなった。

3つ目が一番たちが悪い。古い索引は、エラーを出さない。 壊れた索引なら気づける。だが古い索引は、最新に見える過去の答えを、自信たっぷりに返す。たとえば、ある構成を「必須」としていたADRが翌日に「任意」へ改訂されたとする。索引が前日のままなら、AIは前日の「必須」を根拠として引用し、それを前提に実装やレビューを進める。引用元のパスも行番号ももっともらしいので、読んだ人間も気づきにくい。図書館でいえば、本を入れ替えたのに目録カードだけ古いまま、という状態で、しかも司書はカードを信じて本を探しに行く。

この「頻繁に変わるものの索引は、作った瞬間から古い」という問題は、当社だけの発見ではない。AIコーディングエージェントのClineは2025年5月、公式ポストで「Clineはコードベースに索引を作らない。RAGも、埋め込みも、ベクタDBも使わない。これは制限ではなく、意図的な設計判断だ」と公言している。

理由の筆頭が索引の鮮度で、公式ブログの言葉を借りれば、索引とは定義からして「時間の止まったスナップショット」（”An index, by definition, is a snapshot frozen in time.”）であり、進化し続けるコードと必ずズレていくからだ。RAG構築の講座を主宰するJason Liu氏のような推進側の専門家までが、この判断への賛同を公言している。対象がコードか設計文書かの違いはあれど、「頻繁に変わるものを索引で追いかけない」という論理は、当社が痛感したものとまったく同じである。

鮮度保証を真面目にやったら、作業記録が200件になった

ここで当社が取った行動は、たぶん多くのチームと同じで、「ならば鮮度を機械的に保証する仕組みを作ろう」だった。7月21日から29日にかけて、段階的に仕組みを足していった。

• embeddingモデルの取得を固定する。どのモデルの、どの版の、どのファイルを使ったかをハッシュで記録し、ライセンスも確認して、別の人がレビューしてから使う
• 依存パッケージを丸ごと固定する。Pythonの実行環境に入っている全パッケージのファイルごとのハッシュを記録し、1バイトでも違えば起動しない
• 再構築を段階化する。いきなり現行の索引を上書きせず、別の場所に新しい索引を作り、検索で検証し、レビューを経てから差し替える。途中で失敗しても古い索引を失わない
• 索引の元になった文書の集合を固定する。どのブランチの、どのコミットの、未コミット分はどのファイルまでを含めたかを記録し、作成前後でファイルが1つでも変わっていたら止める

ひとつひとつは真っ当な対策だと思う。実際、この仕組みは何度も「正しく」止まった。実行ファイルのパーミッションが足りずに起動が拒否されたとき。パッケージ管理ツールが自動生成するメタデータに空欄のハッシュが2,700件以上あり、それを「改竄の可能性あり」と判定して停止したとき。モデルの取得にネットワークが要るのに、作業環境の外部通信が閉じていたとき。どれも、仕組みが設計どおりに疑って止めたのである。

だが、そのたびに原因を調べ、直し、別の担当がレビューし、監査し、もう一度試す。当社の開発は実装・独立レビュー・最終監査を分離しているので、1回の修理で3種類の記録が残る。9日間でこの内部ツールに関する作業記録は約200件に達した。そして気づいたときには、製品の機能でもなんでもない検索ツールの修理が、本来のフェーズの完了——データ層の技術選定を閉じること——を止めていた。鮮度を保証するための仕組みが、フェーズの完了条件に組み込まれていたからである。

7月31日の決断 — 直すのをやめ、捨てる

7月31日、プロジェクトの責任者が廃止を決めた。理由は3つに整理されている。

1. 並行する作業コピーと頻繁な正本更新に対して、索引の鮮度を安全かつ低コストに保証できない
2. 古い索引が最新の判断と誤認されるリスクを、運用ルールだけでは消せない
3. 製品の統制ではない内部ツールの修理が、フェーズ完了のクリティカルパスを塞いでいる

廃止の中身も、曖昧にしなかった。使わない、更新しない、再構築しない、検証しない、修理を再開しない。過去の検索結果を設計・実装・レビュー・監査の根拠に使わない。一方で、ツールのソース、テスト、固定した環境の記録、失敗や修理の記録は、消さずに読み取り専用で残す。「なかったこと」にはしない。

代わりに何をするか。正本文書を直接読む。それだけである。AIエージェントには、判断の根拠にした文書のパスと行、参照したブランチとコミット、未コミットの変更の有無を記録させる。並行するコンテキスト間の同期は、検索ではなく、人間の判断記録と明示的な引き継ぎ文書で行う。検索の便利さは失ったが、「何を根拠にしたか」は前より明確になった。

一般化 — 社内RAGを入れる前に確かめたいこと

当社の失敗を、社内RAGを検討している人向けのチェックリストにしておく。

• その文書群は、どのくらいの頻度で変わるか。月に数回なら「更新したら再構築」で回る。日に数回なら、再構築の運用そのものが仕事になる
• 文書を同時に編集する人（やAIのコンテキスト）は何人いるか。複数なら、索引が「誰の、いつの状態」を写したものかを説明できる仕組みが要る
• 古い答えが返ってきたとき、誰がどう気づくか。検索結果に「索引の作成時刻」と「元文書の更新時刻」を並べて出すだけでも、事故はかなり減る
• 索引が古いときの被害はどの程度か。社内FAQなら笑い話で済む。設計判断や監査の根拠に使うなら、古い索引は誤った判断を量産する
• 正本は別にあるか。RAGの検索結果が正本扱いされ始めたら、それは設計上の事故である。検索は入口で、根拠は原文、を守れるか
• そもそも、検索できないとどれだけ困るか。文書が100本程度で、一覧と目次が整っているなら、「全部の見出しを読む」ほうが速くて確実なことは多い

当社の場合、最後の項目に戻ってきた。設計の正本を数十本の範囲に保ち、索引を持たず、原文を読む。地味だが、いまのところ一番事故が少ない。

念のため書いておくと、ここでの比較は「RAG対ファインチューニング」ではなく「RAG対、原文を直接読ませる」である。そして、RAGが正解になる状況も明確にある。LlamaIndexのCEOであるJerry Liu氏は、長コンテキスト時代のRAGを論じた2024年3月のポストで、その前提を「ナレッジベースがコンテキストウィンドウに収まらないほど大きい場合」と置いている。

裏を返せば、収まる規模なら選択肢は変わるということだ。文書が数百・数千本あり、全部読ませることが物理的に不可能な組織では、いまもRAGが正道である。当社のように正本を数十本に絞れる現場かどうか、そこが分かれ目になる。

当社も、内部RAGを再導入する可能性を閉じたわけではない。ただし次にやるなら、鮮度の保証方法、並行する作業コピーとの境界、古い索引の拒否、失敗時の挙動、保守の担当者を、作る前に合格条件として決める。過去の索引が残っているから再開する、はやらない。

この判断の賞味期限

本稿は2026年7月末時点の、当社の特定の開発現場での判断である。文書の量、更新頻度、並行度が違えば結論は変わる。そもそも生成AI自体が日進月歩で、それを使った開発のベストプラクティスも数か月単位で塗り替わっている。本稿の困りごとの起点だった「長い会話でルールを忘れる」挙動にしても、モデルの世代が進めば様変わりしうる。本稿の判断は、当時のモデル（GPT-5.5）と道具立てを前提にした一つのスナップショットとして読んでほしい。「社内RAGはやめておけ」ではなく、「索引の鮮度を誰がどう保証するかを先に決めろ」という話として受け取ってもらえれば、賞味期限を超えて役に立つはずだ。

まとめ

• 設計文書を検索する社内RAGを6月初めに作り、7月末に全面廃止した。理由は精度でも費用でもなく、索引の鮮度を安全に保証できなかったこと
• 導入直後は効果があった。ルール忘れが減り、文書を探す往復が減り、新しいAIコンテキストの立ち上がりが速くなった
• しかし、更新が1日数回・並行する作業コピーが複数、という条件では「更新したら再構築」が破綻する。そして古い索引はエラーを出さず、最新に見える過去の答えを返す
• 鮮度を機械的に保証しようとした結果、内部ツールの修理が約200件の作業記録を生み、本来のフェーズ完了を止めた
• 廃止後は正本文書を直接読み、根拠のパス・行・コミットを記録する運用へ戻した。「索引を作らない」は、コーディングエージェント界隈でも設計判断として公言され始めている
• ナレッジベースがコンテキストに収まらないほど大きいなら、いまもRAGが正道。分かれ目は、文書の量と変わる速さにある

作ったものを捨てる判断は、作る判断より重い。ただ、今回は捨てたことで「何を根拠に判断したか」がむしろ見えやすくなった。便利さより追跡可能性を取った、というだけの話である。

よくある質問

Q1. 社内文書RAGとは何か

社内の文書をチャンクに分けてベクトル化し、質問と意味の近い部分を検索してAIに渡す仕組みである。AIが知らない社内情報を根拠つきで答えさせるために使われる。本稿では、設計文書をAIコーディングエージェントが作業前に探すための内部ツールとして試作した。

Q2. RAGのindex（索引）が古いとどうなるか

索引は作成時点の文書のコピーなので、元の文書を直しても自動では変わらない。古い索引は、エラーを出さずに過去の内容を最新の答えのように返すため、改訂前の設計判断が根拠として引用される事故が起きる。検出する仕組みがなければ、人間も気づきにくい。

Q3. 社内RAGの索引はどのくらいの頻度で更新すべきか

文書の更新頻度に合わせる必要がある。月に数回の更新なら「更新したら再構築」で運用できるが、日に数回の更新や複数人の同時編集がある環境では、再構築の運用自体が負担になる。本稿のケースでは、2週間で文書が67件から84件へ増え、同じ文書が日に何度も更新されたことが破綻の一因だった。

Q4. 社内RAGをやめる判断基準は何か

索引の鮮度を安全かつ低コストに保証できない、古い索引が最新と誤認されるリスクを運用ルールで消せない、ツールの維持が本来の業務のクリティカルパスを塞いでいる、の3つが揃ったときである。本稿では、製品の機能ではない内部ツールの修理が本来のフェーズ完了を止めた時点で廃止した。

Q5. 社内向けの文書検索RAGと、製品に組み込むRAGは何が違うか

開発チームが自分たちのために運用する内部ツールか、顧客へ提供する製品機能かという違いがある。製品に組み込む場合は、鮮度の保証に加えて、権限、監査、障害時の挙動まで要件として設計することになる。本稿の教訓——索引の鮮度を誰がどう保証するかを先に決める——は、どちらにも当てはまる。

Q6. AIコーディングエージェントに設計文書を読ませる方法で、RAG以外の選択肢はあるか

ある。設計の正本文書を数十本の範囲に保ち、一覧と目次を整えて原文を直接読ませる方法である。本稿では廃止後にこの方法へ戻し、根拠にした文書のパス・行・ブランチ・コミットを記録させている。文書が少ないうちは、検索より確実で速いことが多い。

Q7. 社内RAGを再導入するなら、どんな条件が必要か

鮮度の保証方法、並行する作業コピーとの境界、古い索引の拒否、ネットワークやキャッシュの扱い、失敗時の挙動、保守の担当者を、最初から合格条件として定義することである。過去の索引やモデルが残っているからといって、そこから再開しないことも重要になる。

参考リンク

• Cline公式ポスト「Cline doesn’t index your codebase.」（2025-05-27）
• Why Cline Doesn’t Index Your Codebase (And Why That’s a Good Thing) — Cline Blog
• Jason Liu氏のポスト「why your coding agents don’t need rag anymore」（2025-07-10）
• Jerry Liu氏のポスト「What does RAG look like in a long-context LLM future?」（2024-03-01）
• Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma Research
• Qdrant Documentation
• sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2 — Hugging Face
• 政府AI「源内」はさくらのクラウドで動くのか — OSS公開から3か月、国産クラウドでMVPを動かすまで
• プロンプト発見からCowork運用へ──「型作り」と「実行」の分業

さくらのAI Engineに Kimi-K2.7-Code が乗りました。手元の OpenAI SDK のコードは base_url の差し替えでそのまま向けられますが、model に Kimi-K2.7-Code と書くと通りません。公式の告知に載っている文字列は、頭に preview/ が付いた preview/Kimi-K2.7-Code です。

プレビュー提供中のモデルには、この接頭辞が付きます。一方でマニュアルのサンプルコードは正式提供の gpt-oss-120b のままなので、サンプルだけを見て書くと最初の一投目で詰まります。ここを含めて、動かすまでに引っかかる箇所を先に潰しておきます。

この記事でわかること

• さくらのAI Engineで Kimi-K2.7-Code を動かす最短手順と、正しいモデル名
• 手元のコードを base URL の差し替えだけで OpenAI SDK から呼ぶ方法
• 無料枠の月3,000リクエストでどこまで試せるか、そして thinking が課金に効いてくる理由
• 速度と失敗率とコストを自分で測るための 実測テンプレ

なぜ今これか

コード生成モデルを使うとき、多くの人は OpenAI か Anthropic に API を投げています。ただ案件によっては、データを国内に置きたい、請求と権限を分けたい、特定ベンダーに寄せきりたくない、といった要件が先に立ちます。

さくらのAI Engine は2025年9月24日に一般提供が始まった推論API基盤で、GPUクラウドの高火力を土台にしています。同じタイミングで、さくらの生成AIプラットフォームは「さくらのAI」へ名称が変わり、AI Engine がその中核に据えられました。公式は、モデルの実行と通信をすべて国内クラウドで完結させ、外部へデータを送らないと明記しています。モデル提供元にもデータが渡らないため、学習に使われる心配もないという書き方です。社内のコードを丸ごと投げるコード生成用途では、ここが実質的な選定理由になります。

そのAI Engineに、Moonshot AI の Kimi-K2.7-Code が2026年7月28日からパブリックプレビューで乗りました。API は OpenAI 互換なので、既存の OpenAI SDK のコードをほぼそのまま国産クラウド上のモデルに向けられます。しかも Chat Completions は月3,000リクエストまで無償です。まず触るハードルはかなり低い。

さくらのクラウド上でAIを動かす話はさくらのクラウド シンプルAI（CR版）を申請から疎通まで最短で通すにもあります。合わせて読むと、申請まわりの温度感がつかめます。

準備。アカウントトークンを発行する

1. コントロールパネルにアクセスして利用規約に同意し、プランを選ぶ
2. 左メニューのアカウントトークンから作成に進み、トークン名を入れて発行する

トークンは <UUID>:<シークレット> というペアの形式で、作成時に一度しか表示されません。公式マニュアルにも、再度表示されないのでコピーして安全な場所に保存するようにと書かれています。ここでコピーし損ねると作り直しです。

ひとつ紛らわしいのが、さくらのクラウド本体のAPIで使うアクセストークンとシークレットとは別系統だという点です。インフラ管理側の鍵は AI Engine では使えません。AI Engine のコントロールパネルで発行したものを用意してください。

最短で叩く。curl

curl --location 'https://api.ai.sakura.ad.jp/v1/chat/completions' \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer <UUID>:<シークレット>' \
  --header 'Content-Type: application/json' \
  --data '{
    "model": "preview/Kimi-K2.7-Code",
    "messages": [
      {"role": "system", "content": "あなたは熟練のソフトウェアエンジニアです。"},
      {"role": "user", "content": "Pythonで、指定ディレクトリ配下の重複ファイルをハッシュで検出する関数を書いて。"}
    ],
    "temperature": 0.2,
    "max_tokens": 4000,
    "stream": false
  }'

エンドポイントは https://api.ai.sakura.ad.jp/v1/chat/completions、認証は Authorization: Bearer <アカウントトークン> だけです。OpenAI の Chat Completions を触ったことがあれば、見慣れた形のはずです。

max_tokens を4000にしてある理由は後述します。ここを小さくすると痛い目を見ます。

モデル名は preview/ 付き

冒頭に書いたとおり、パブリックプレビューのモデルには preview/ が付きます。7月28日の提供開始告知に、model パラメータへ指定する文字列として preview/Kimi-K2.7-Code が明記されています。

これはこのモデル固有の話ではなく、プレビュー全般の命名規則です。Anthropic互換のMessages APIで使えるモデルも preview/Kimi-K2.6 という表記になっています。逆に正式提供の gpt-oss-120b や llm-jp-3.1-8x13b-instruct4 には接頭辞が付きません。プレビューか正式提供かで書き分けが要る、と覚えておけば迷いません。

裏を返すと、モデル名の正解はマニュアルではなく各モデルの提供開始告知にあります。新しいモデルを試すときは、まず告知ページを開くのが早い。

OpenAI SDK から使う。差し替えは2行

既存の Python コードなら、base_url と api_key を差し替えるだけです。

from openai import OpenAI

client = OpenAI(
    base_url="https://api.ai.sakura.ad.jp/v1",   # ← ここだけ差し替え
    api_key="<UUID>:<シークレット>",              # ← アカウントトークン
)

resp = client.chat.completions.create(
    model="preview/Kimi-K2.7-Code",
    messages=[
        {"role": "system", "content": "あなたは熟練のソフトウェアエンジニアです。差分だけを返してください。"},
        {"role": "user", "content": "このReactコンポーネントのuseEffectの依存配列漏れを直して: ..."},
    ],
    temperature=0.2,
    max_tokens=4000,
)
print(resp.choices[0].message.content)

環境変数派なら OPENAI_BASE_URL=https://api.ai.sakura.ad.jp/v1 と OPENAI_API_KEY=<アカウントトークン> を設定すれば、OpenAI を前提にした多くのツールがそのまま向きます。

ただし Anthropic SDK 経由で使いたい場合は事情が変わります。Messages API で使えるモデルは現状 preview/Kimi-K2.6 だけで、K2.7-Code は含まれていません。さくらの7月28日の告知でも、対応APIは Chat completions と書かれています。Claude Code のようなAnthropic互換前提のツールから K2.7-Code を呼ぶ選択肢は、いまのところありません。

Kimi K2.7 Code はどういうモデルか

Moonshot AI の公式情報によると、K2.7 Code は総パラメータ1Tのミクスチャー・オブ・エキスパートです。384のエキスパートから8つを選び、トークンあたり32Bがアクティブになります。コンテキスト長は256Kトークン、ライセンスは Modified MIT License です。

性格としてはコーディング特化のagenticモデルです。K2.6比のベンチマークでは、Kimi Code Bench v2 が50.9から62.0へ、Program Bench が48.3から53.6へ伸びました。推奨設定は temperature 1.0、top_p 0.95 とされています。

ここで押さえておきたいのが、このモデルは非thinkingモードに対応しておらず、常に思考を有効にして動くという点です。K2.6と比べて thinking トークンの消費量は約30%減ったとされていますが、ゼロにはできません。この性質があとでコストと max_tokens の両方に効いてきます。

もう一点、さくらの告知はこのモデルを画像とテキストを組み合わせた理解と生成が可能なマルチモーダルモデルとして紹介しています。想定用途にはドキュメント理解や画像キャプション生成、マルチモーダルQAも挙がっています。コード特化だが画像も入る、という理解が正確です。

コスト感

Kimi-K2.7-Code の単価は次のとおりです。いずれも税込で、1万トークンあたりの金額です。

加えて Chat Completions は月3,000リクエストまで無償です。基盤モデル無償プランと呼ばれています。個人の検証や社内の小さな自動化なら、無料枠だけで回り切ることも多いはずです。無償枠を超えた場合は自動で課金に切り替わるのではなく、レート制御がかかる形になります。

出力課金が入力の約10倍なので、コストは基本的に出力トークン量で決まると考えておくと見積もりしやすい。ざっくり、1回の生成で出力2,000トークンなら約1.0円。1日20回テストしても月あたり数百円のオーダーです。

ただしこの試算はそのままでは甘い。thinking の出力も課金対象だからです。K2.7-Code は思考を切れないので、画面に見えている回答が短くても、裏で消費したトークンぶんは請求に乗ります。体感の単価は「見えている回答の長さ」より高くなると思っておいてください。

この数字が高いのか安いのかは、単体では判断できません。そこで提供中のモデルを全部並べてみます。

いずれも1万トークンあたり、無料枠は月3,000リクエストで共通です。CPU実行の小型モデルまで含めて図にすると、差がはっきりします。

K2.7-Code は出力単価でプレビュー中の最高値です。入力は K2.6 より安いのに出力は1.7倍近い。長い生成を回す使い方ほど、他モデルとの差が開きます。

max_tokens を絞ると回答側が削られる

thinking が常時オンであることの実務的な影響がここに出ます。max_tokens が縛るのは出力トークンの総量で、思考もそこに含まれます。そして K2.7-Code は思考を切れません。つまり値を小さくすると、思考だけで予算を使い切り、可視の回答が削られるという筋道が成り立ちます。

短い応答が欲しいときほど max_tokens を絞りたくなりますが、このモデルでは逆効果になりえます。予算そのものは数千トークン確保しておいて、出力の長さはプロンプト側で指示するほうが安全です。この記事のサンプルを4000にしてあるのはそのためです。応答が短すぎる、あるいは途中で切れると感じたら、まずここを疑ってください。

自分の用途で測る

ここからが本題です。プレビュー中のモデルは、公開ベンチの順位より自分のプロンプトでの挙動のほうが当てになります。しかも K2.7-Code は thinking が常時オンなので、他モデルの感覚をそのまま持ち込むとコストの読みを外します。

そこで、そのままコピーして回せるベンチマークを置いておきます。汎用の数字を引用するのではなく、あなたの環境の数字を出すためのものです。

測る指標は次のものです。

• レイテンシ。初回トークンまでと、全体の両方
• スループット。tokens/sec
• 失敗率。タイムアウトと5xxとレート制限の割合を、100回から500回の連続実行で
• 実効コスト。usage の prompt と completion のトークン数から円換算
• 実効コンテキスト長。Moonshot公式は256Kだが、AI Engine 側の上限は公表されていない
• 生成品質。同一プロンプトを OpenAI や Anthropic と並べて、主観評価かテスト通過率で

スクリプトはこちらです。トークンを差し替えればそのまま動きます。

import time, statistics
from openai import OpenAI

client = OpenAI(base_url="https://api.ai.sakura.ad.jp/v1", api_key="<Token>")
N = 50
lat, ok, in_tok, out_tok = [], 0, 0, 0
for i in range(N):
    t = time.time()
    try:
        r = client.chat.completions.create(
            model="preview/Kimi-K2.7-Code",
            messages=[{"role":"user","content":"二分探索をPythonで。境界条件のテストも。"}],
            temperature=0.2, max_tokens=4000,
        )
        lat.append(time.time()-t); ok += 1
        in_tok += r.usage.prompt_tokens; out_tok += r.usage.completion_tokens
    except Exception as e:
        print("fail:", e)
print(f"成功率 {ok}/{N}  中央値レイテンシ {statistics.median(lat):.2f}s")
print(f"コスト概算 {(in_tok/10000*0.52)+(out_tok/10000*5.04):.1f}円")

completion_tokens には thinking のぶんも入るので、この概算は実請求に近い値になります。見えている回答の長さと突き合わせると、思考にどれだけ使っているかも見えてきます。ここが他モデルと一番ずれるところなので、最初に一度は確認しておく価値があります。

50回なら無料枠の3,000リクエストに対して十分な余裕があります。無償枠を超えても自動で課金に切り替わるのではなく、レートリミットがかかる形です。

比較対象を作るなら、同じスクリプトの base_url と model だけ差し替えて、普段使っているモデルにも同じプロンプトを流してください。差し替えが1行で済むのがこの構成の利点なので、そのまま横並びのベンチになります。

正直なところ

ここまでの手順で動きますが、本番に載せる前に知っておいたほうがいいことがいくつかあります。

• トークンは再表示されない。<UUID>:<シークレット> の形式で一度きりなので、パスワードマネージャに即保存を。
• モデル名はマニュアルではなく告知ページを見る。マニュアルのサンプルは正式提供の gpt-oss-120b のままで、プレビューモデルの識別子は各モデルの提供開始告知に書かれています。
• API種別によって使えるモデルが違う。K2.7-Code は Chat Completions での提供です。Anthropic互換の Messages API は preview/Kimi-K2.6 のみ。Responses API での K2.7-Code 対応可否は公式に確認できませんでした。ちなみに Responses API 自体、画像入力とマルチターン会話には未対応です。
• プレビューの条件は緩くない。公式は、予告なく提供を終了する場合があり、提供期間中も安定性や応答品質を保証せず、動作や仕様が変更となる可能性があると書いています。SLAの明示もありません。プロダクションに載せるなら、モデル差し替えを前提にした抽象化層を1枚挟んでおくのが無難です。
• レート制限の具体値は非公開。無償枠を超えるとレートリミットがかかると書かれているだけで、RPM や TPM の数値は公開されていません。連続実行する前に小さく試してください。
• さくら上での実効コンテキスト長も未公表。Moonshot公式は256Kですが、AI Engine 上で同じだけ入るかは確認できません。長いコンテキストを前提にするなら、測る項目に入れてください。
• 品質と速度は自分の用途で測ってから。汎用ベンチの数字を当てにしすぎない。だからこの記事は実測テンプレを付けています。

エージェントとして常駐させる方向まで踏み込むなら、常駐AIエージェントの落とし穴3つで挙げた権限と監査とコストの話がそのまま効いてきます。

よくある質問

Q. モデル名を Kimi-K2.7-Code と書いたらエラーになりました

preview/ が抜けています。パブリックプレビューのモデルは preview/Kimi-K2.7-Code です。正式提供モデルには接頭辞が付かないので、そちらのサンプルを流用すると間違えます。

Q. 応答が短すぎる、途中で切れます

max_tokens が小さすぎる可能性があります。K2.7-Code は thinking を切れず、思考も出力トークンの予算を使います。まず4000程度まで上げて試してください。

Q. さくらのクラウドのAPIキーをそのまま使えますか

使えません。インフラ管理APIのアクセストークンとシークレットは別系統です。AI Engine のコントロールパネルでアカウントトークンを発行してください。

Q. Claude Code から使えますか

現状は使えません。Anthropic互換の Messages API に対応しているのは preview/Kimi-K2.6 で、K2.7-Code は Chat Completions での提供です。

Q. 無料枠だけでどこまで試せますか

Chat Completions は月3,000リクエストまで無償なので、100回規模の計測なら十分に収まります。API種別ごとに枠が違い、ベクトル埋め込みは月10,000リクエスト、音声の文字起こしと音声合成はそれぞれ月50リクエストです。枠を超えると課金ではなくレートリミットがかかります。

まとめ

• さくらのAI Engine は OpenAI SDK の base_url を差し替えるだけで Kimi-K2.7-Code を叩ける
• モデル名は preview/Kimi-K2.7-Code。プレビューモデルには接頭辞が付く
• 月3,000リクエスト無料、出力は1万トークンあたり5.04円で、コストは出力量が主
• thinking は常時オン。課金に乗るうえ、max_tokens を絞ると本文が空で返る
• Anthropic互換の Messages API では使えない。Chat Completions での提供
• 入門で止めず、自分の用途でレイテンシと失敗率とコストを実測するところまでやる

国産クラウド上でコード生成APIを、既存資産をほぼ壊さずに試せるのは大きい。まずは無料枠で、自分のプロンプトを1本流してみるところからどうぞ。

参考（一次情報）

• Kimi-K2.7-Code 提供開始のお知らせ（2026-07-28）
• さくらのAI Engine 製品ページ（モデル・料金）
• 利用手順（マニュアル）
• さくらのAI Engine マニュアル目次
• Inference API リファレンス
• Responses API・Messages API 提供開始のお知らせ（2026-05-20）
• さくらのAI Engine 一般提供開始のプレスリリース（2025-09-24）
• Moonshot AI Kimi K2.7 Code
• moonshotai/Kimi-K2.7-Code（HuggingFace）
• コントロールパネル
• Playground

2026年4月24日、デジタル庁がガバメントAI「源内」のソースコードを公開した（当時の解説記事）。リポジトリを眺めながら考えていたのは、「これはAWSの外でも動くのか」という素朴な問いだった。源内はガバメントクラウド上のAWSを前提に構築されており、公開されたコードにもCDK、Cognito、DynamoDBといった依存がそのまま残っている。コードが読めることと、自分の環境で動かせることのあいだには、かなりの距離がある。

EastCloudでは2026年6月、この距離を実測するために、源内のWebフロントエンドをさくらのクラウド上で動かす検証プロジェクトを社内で立ち上げた。先に結論を書いておく。エージェントを選び、実行し、さくらのAI Engineから回答が返ってくるという最小限の体験は、さくらのクラウドのマネージドサービスの組み合わせで成立した。ただし、源内の全機能が動いたわけではない。本稿では、何を動かし、何を意図的に後回しにし、どこでつまずいたかを記録する。

前提 — これは公式の移植ではない

最初に断っておきたい。ここで扱うのは、当社が社内で「源内 on Sakura」と呼んでいる検証実装であり、デジタル庁の公式プロジェクトでも、デジタル庁が認めた移植版でもない。公開されたOSSを、ライセンスの範囲で第三者が別のクラウドへ載せてみた、という位置づけである。

ライセンス面は少し注意がいる。源内のWeb側リポジトリ genai-web はMITライセンスが中心だが、一部のLambdaやCDK関連ファイルはAmazon Software Licenseの対象になっている。取り込む範囲を決める際には、ファイル単位でヘッダを確認した。今回の検証では上流のv1.0.7を固定し、取り込んだ範囲・除外した範囲・当社で改変した範囲をコミットで分離して、どこまでが源内由来でどこからが改修かを後から説明できるようにしている。AWS依存の塊であるインフラ定義（CDK）は、そもそも持ち込んでいない。

なぜさくらのクラウドで動かすのか

理由は源内そのものの文脈にある。源内は、政府のAI基盤を特定ベンダーへの依存を抑えながら育てるという流れの中にいて、国産LLMの選定もOSS公開もその一環と読める。一方、受け皿となる国内インフラの側では、さくらのクラウドがガバメントクラウドの対象クラウドサービスとして正式採択された（経緯はこちらの記事）。

つまり「政府製のAIアプリケーション資産」と「国産のガバメントクラウド対応インフラ」が、それぞれ別の理由で揃いつつある。なら実際に載せてみればいい、というのが今回の動機である。なお、EastCloudはさくらインターネットのパートナーとして日常的にさくらのクラウドを扱っているが、本稿は検証の記録であり、動いたものは動いた、動かなかったものは動かなかったとそのまま書く。

源内のAWS依存を数えるところから始めた

移行でやりがちな失敗は、AWSのサービス名を国産クラウドのサービス名へ1対1で読み替えて、そのまま持ち込もうとすることだ。今回はまず、源内のWeb側が実際に何へ依存しているかを棚卸しし、そのうえで「初期の最小構成に必要なもの」と「今は置き換えないもの」を切り分けた。主要な依存と今回の扱いは次のとおり。

表にすると整然として見えるが、実際の判断はもう少し泥臭い。たとえばLambdaは「Lambdaの代替探し」をすると失敗する。HTTPの同期APIなのか、キュー処理なのか、スケジュール実行なのかで置き換え先は変わるからで、今回はHTTP同期APIだけを対象に、AppRun上の常駐Goプロセスへ寄せた。キューやスケジュールの置き換えは、それを必要とする機能に手を付けるときに個別に考える。

最小構成のかたち

今回の構成はこうなった。

設計上こだわった点が3つある。

第一に、AIの呼び出しをサーバサイドへ閉じたこと。ブラウザからAI Engineを直接叩かず、APIキーもフロントエンドへ出さない。エージェント定義のうちシステムプロンプトのような実行時情報はサーバ側だけが持ち、画面には表示用の情報だけを渡す。

第二に、失敗を成功に見せないこと。プロバイダが未設定なら「未設定」というエラーで止める。AI Engine側でエラーが返れば、サンプル回答やそれらしいダミーで取り繕わず、安全なエラーとして返す。この種の検証では一般に、ダミー応答を本物の成功と取り違えたまま進んでしまう事故が起きやすい。今回は、そうならないことを失敗系のテストで確認しながら進める方針を最初に決めた。

第三に、追跡IDの境界を決めたこと。障害調査にはリクエストの追跡IDが要る。ただ、AIプロバイダ側の内部IDをそのままブラウザへ返すと、外部サービスの内部情報を利用者へ露出することになる。今回はゲートウェイが発行するリクエストIDだけをクライアントへ返し、プロバイダ側IDとの対応はサーバのログに閉じた。

認証について補足しておく。今回の「共有アクセスゲート」は、検証環境に鍵をかけるための入口であって、ユーザー認証ではない。個別アカウントも、テナントも、権限管理も、監査証跡も、ここからは何も主張できない。Cognitoの置き換えは、この検証の範囲外として明確に残してある。

動いたもの

最終的に、次の一連の流れがさくらのクラウド上で動いた。

• ブラウザでアクセスし、共有アクセスゲートを通過する
• エージェントの一覧と詳細を表示する
• テキスト生成系のエージェントを選んで実行する
• さくらのAI Engineが生成した回答が画面に返る

成功パターンだけでなく、失敗パターンも確認した。プロバイダ設定を意図的に壊した状態で実行すると、フェイクの成功応答に化けることなく、エラーとして返ってくる。地味だが、この失敗系の確認こそ検証の本体だと思っている。

動かしていないもの

ここを曖昧にすると「源内がさくらで完全に動いた」という誤解が独り歩きするので、動かしていないものを明記する。

• チャット履歴・実行履歴の永続化（データベースを使っていない）
• RAG、ファイルアップロード、画像生成などの拡張機能
• ユーザー別の認証・テナント・権限・管理画面
• 利用量・コスト管理、監査ログの永続化
• 本番運用を前提とした監視・アラート・運用手順

つまり動いたのは「源内の最小の背骨」であって、源内互換の完成品ではない。背骨が通ることと、全身が動くことは別の話である。ただ、この距離感そのものが、移行を検討する人にとっては有用な情報になるはずだ。

つまずいた壁 — 3つだけ挙げる

検証で越えた壁のうち、ほかの人も踏みそうなものを3つ記録しておく。

壁1. SPAのdeep linkが404になる

源内のフロントエンドはReact RouterのSPAで、/chat/:id のようなURLへの直接アクセスに対して、配信側が index.html を返す仕組みを前提にしている。AWSではCloudFrontのカスタムエラーレスポンスが担っているこの挙動が、さくらの静的配信には見当たらなかった。今回はAppRun上のゲートウェイでルートを分類して解決した。ここは論点が多いので、続編の記事で検証内容ごと掘り下げる。

壁2. シークレットの注入

シークレットマネージャを秘密情報の正本にしたが、AppRun（共用型）のアプリケーションからシークレットマネージャの値を直接参照する方法は、検証時点では確認できなかった。今回は検証限定の暫定運用として、同じ値をAppRun側へ手動登録する二重管理にした。二重管理は更新漏れの温床になるので、長く続けたい形ではない。ここはAppRunからシークレットマネージャを直接参照できる公式対応を待ちたいところで、それまでは、APIやIaCで両者の同期を自動化して更新漏れを防ぐのが現実的だと考えている。

壁3. どこまで隠すか

AIプロバイダの生のエラー本文をそのまま返すと、内部情報が漏れる。かといって全部を握りつぶすと調査ができない。公開してよいエラーコードとメッセージを許可リストで定め、それ以外はサーバログ側で追う、という整理に落ち着いた。

なお、この種の検証結果には賞味期限がある。上記はいずれも2026年6月中旬から下旬にかけての実機検証に基づくもので、さくらのクラウドは機能追加のペースが速い。実際、当社の別の検証では、一度「構造的に不可能」と結論づけた制約が、その後の機能提供で解けた例もあった。重要な判断の前には、必ず現行の公式ドキュメントを確認してほしい。

さくらのクラウドに期待したいこと

検証を終えて、要望を2つに絞るならこうなる。1つは、静的配信側での任意ルートfallback。存在しないURLへのアクセスを指定ドキュメントへ返せれば、SPAはオブジェクトストレージとウェブアクセラレータだけで完結し、AppRunはAPIに専念できる。もう1つは、AppRunからシークレットマネージャへの直接参照。この2つが揃うと、AWSで当たり前だった構成との段差がだいぶ埋まる。

一方で、擁護もしておきたい。AppRunにフロントエンドとゲートウェイを同梱する構成は、回り道のようでいて、どのルートを画面へ返しどのルートをAPIとして扱うかが設計として明示される利点があった。そして何より、コンテナレジストリにイメージを置き、AppRunへ載せ、AI Engineへつなぐという流れは素直で、最小構成のMVPまでは想像より短い距離で到達できた。

まとめ

• 源内のWebフロントエンドは、さくらのクラウド（AppRun + AI Engine + シークレットマネージャ等）の上で、エージェント実行の最小体験まで動いた
• 動かしていない領域（履歴・RAG・認証・運用堅牢化）は多く残っており、「動いた」と「置き換えられた」は別物である
• AWS依存はサービス名の読み替えではなく、責務単位で棚卸ししてから置き換える
• 検証結果には日付を付ける。クラウドの制約は動く

源内のOSS公開を「読む」ところから「動かす」ところへ進めてみて、参照実装としての政府OSSという設計の意味が、少しだけ体感として分かってきた。続編では、今回さらりと流したSPA deep linkの壁を、検証で確認できた事実ベースで掘り下げる。

よくある質問

Q1. 政府AI「源内」とは何か

デジタル庁が内製で開発・運用している政府職員向けの生成AI利用環境である。2026年4月にWeb側の genai-web とアプリ側の genai-ai-api がGitHubで公開され、第三者もライセンスの範囲で利用できる。

Q2. 源内のソースコードは商用利用できるか

中心はMITライセンスであり商用利用できる。ただし一部のファイルはAmazon Software Licenseの対象なので、利用する範囲をファイル単位でヘッダ確認したい。

Q3. 源内はAWS以外のクラウドでも動くか

そのままでは動かない。Cognito・DynamoDB・CloudFrontといったAWS前提の依存を棚卸しし、責務単位で代替へ置き換える必要がある。本記事の検証では、さくらのクラウド上でエージェント実行の最小構成が動作した。

Q4. さくらのクラウドで源内を動かすには、どのサービスを使うか

本検証では、AppRun（コンテナ実行）、さくらのAI Engine（モデル実行）、シークレットマネージャ、コンテナレジストリを組み合わせた。チャット履歴の永続化やユーザー別認証は、検証範囲に含めていない。

Q5. さくらのAI Engineとは何か

さくらインターネットが提供する生成AIの実行基盤で、APIから各種モデルを呼び出せる。本検証では、AWSのBedrockが担っていたモデル実行の置き換え候補として、サーバサイドのアダプタ経由で利用した。

Q6. 「源内 on Sakura」はデジタル庁の公式プロジェクトか

違う。EastCloudが社内検証のために使っている呼び名であり、デジタル庁とは関係のない非公式の検証実装である。

Q7. 源内をさくらのクラウドで動かすときの一番の壁は何か

2026年6月の検証時点では、SPAのdeep link（URL直接アクセス）への対応と、AppRunからのシークレット直接参照の2点だった。前者はAppRun上のゲートウェイで解決し、後者は検証限定の暫定運用で回避した。

参考リンク

• digital-go-jp/genai-web — GitHub
• digital-go-jp/genai-ai-api — GitHub
• さくらのクラウド
• さくらのクラウド マニュアル
• デジタル庁が政府AI源内をオープンソース公開 — コードの中身と行政DXの現在地
• さくらのクラウドがガバメントクラウド正式採択。次に問われるのは「誰が導入・運用できるか」
• さくらのクラウドでフルマネージドなAIエージェント実行基盤を構築した話