受託開発の現場では、案件によって開発環境の前提がまるごと変わります。ある案件ではコーディングエージェントを普通に使い、別の案件では「ソースコードを外部サービスに送信しないこと」が契約書に明記されている。金融、医療、公共、そして製造業の一部。珍しい条件ではありません。
問題は、その案件だけ生産性が数年前のまま取り残されることです。同じチームが同じ週に、片方では AI にリファクタリングを任せ、もう片方では手で書いている。この差は、見積りにも納期にも効いてきます。
完全にローカルで動くコーディングエージェント
JetBrains は2026年8月、Junie Local の提供を開始しました。同社のコーディングエージェント Junie の、ローカル実行版という位置づけです。
報じられている仕様は次のとおりです。
| 項目 | 内容 |
|---|---|
| 動作環境 | 完全にローカルマシン上で動作。API 利用料・モデル利用料は不要 |
| モデル | 4ビット量子化の Qwen3.6-27B。ダウンロードサイズ約20GB |
| 必要スペック | 64GB RAM を搭載した M5 Mac |
| 導入方法 | Junie 内で /local コマンドを実行するだけ。トークンやクオータの設定は不要 |
| 今後 | NVIDIA RTX 5909 への対応を開発中 |
モデル選定について、あえて新しい Qwen3.8 ではなく Qwen3.6 を選んだと説明されています。理由はタスクの実行速度で、ローカル実行では応答が返るまでの時間がそのまま使い勝手を決めるためです。この判断は、ローカルで動かす製品としては筋が通っています。
Publickey の記事では Claude Sonnet 4.5 と同等の能力があると報じられていますが、これはベンダー側が示す評価であり、自社のコードベースでそのまま再現するとは限りません。 導入するなら、実際の案件のコードで試したうえで判断してください。
「外に出さない」の実際の意味を確認する
導入検討の前に、確認しておくべきことがあります。契約や社内規程で禁止されているのが何なのかです。ここは案件ごとにかなり違います。
- ソースコードの外部送信の禁止なら、ローカル実行は要件を満たします
- AI 生成コードの混入そのものの禁止なら、ローカルかどうかは関係ありません。使えません
- 成果物の権利関係の懸念が理由なら、モデルのライセンスと出力の扱いを別途確認する必要があります
2番目と3番目を1番目だと思い込んで導入すると、あとで問題になります。「AI は禁止」と口頭で言われている案件ほど、何が禁止なのかが書面で確認されていないというのが実感です。まずそこを詰めてください。
端末のスペックが、そのまま導入コストになる
64GB RAM の M5 Mac という要求は、現実の受託開発チームにとって軽くありません。全員の端末を入れ替える話になると、ライセンス費用がゼロであることの意味はかなり薄れます。
現実的な入り方は、該当案件の担当者だけに絞ることです。 外部送信が禁止されている案件が全体の2割なら、その2割を担当するメンバーの端末だけを対象にすればよい。全社標準にする判断は、対応ハードウェアが広がってからでも遅くありません。
この構図は、オンプレミスに AI 推論を置くかどうかの判断と同じです。ローカルで動かす選択は、性能や費用で選ぶものではなく、データを外に出せないという制約から選ぶものです。制約がない案件でわざわざ選ぶ理由はほとんどありません。
任せる範囲は、クラウド版と同じにしない
ローカルで動くモデルは、クラウドの最新モデルと同じ範囲を同じ精度でこなすわけではありません。同じ使い方を前提にすると、期待が外れます。
実務で成立しやすいのは、入力と出力の範囲が閉じている作業です。
- 既存コードの説明。初めて触るモジュールの把握は、ローカルモデルでも十分に役立ちます
- 定型的な変換。命名規則の統一、テストコードの雛形生成、型定義の付与
- レビュー前の自己点検。明らかな抜けや不整合を洗う用途
逆に、設計判断を含む作業や、リポジトリ全体を横断して整合性を取る作業は、期待値を下げておいたほうが安全です。ここは端末のメモリに載る範囲という物理的な制約が効きます。ローカル実行を前提にした処理設計では、どこまでを手元で完結させるかの線引きが結局いちばん重要になります。
提案の段階で確認しておくと、あとが違う
受託の実務でいちばん効くのは、提案や見積りの段階で AI 利用の可否を確認しておくことです。契約後に「使えないと分かった」となると、前提にしていた工数がそのまま崩れます。
確認する内容は多くありません。開発時に使用するツールについて、次の3点を書面でやり取りしておけば足ります。
- ソースコードを外部サービスへ送信してよいか
- 送信が不可の場合、ローカル完結のツールなら差し支えないか
- 成果物に AI が関与したことの記載や報告が必要か
このやり取りは、こちらの制約になるだけではありません。発注元にとっても、AI 利用を一律に禁止するか条件付きで許すかを判断する材料になります。 実際、「クラウドに出さないなら構わない」という回答は珍しくなく、聞かなかったために全面禁止のまま進んでいた案件も見かけます。
見積りに反映するときも同じで、AI を使える前提の工数と、使えない前提の工数を分けて示すほうが話が早くなります。差分が見えると、発注元が条件を緩める判断をしやすくなるためです。
次にやること
まず、現在進行中の案件を、コードの外部送信が禁止されているかどうかで分けてください。 禁止側に該当する案件が1つもないなら、この話は当面必要ありません。
該当する案件があるなら、その制約が契約書のどこに書かれているかを確認してください。 「外部サービスへの送信の禁止」と読めるなら、ローカル実行は選択肢になります。「AI の利用の禁止」と読めるなら、まず発注元と話す必要があります。技術の選定はその後です。
機密性の高い案件での AI 活用の設計、ローカル実行環境の構成、開発フローへの組み込みについては、グリームハブの開発・AI・自動化のご相談で承っています。案件の制約条件によって取れる構成が変わるため、個別にご相談ください。お問い合わせからどうぞ。
