— AI導入を"事業に載せる"ために、いま設計すべきこと（全3回）

こんにちは！Qualitegコンサルティングチームです。

今回の「AI導入を“事業に載せる”ために、いま設計すべきこと」シリーズも、いよいよ第3回です。

第1回では、実際のAI導入事故を通じて、AIエージェントのリスクが単なる技術不良ではなく、権限や運用設計の不在から生まれることを見てきました。第2回では、事故が起きたときに責任をどこに置くのか、法務・契約・組織の観点から責任分解の難しさを整理しました。

では、AI導入を止めずに前に進めるためには、実務として何を先に設計しておくべきなのでしょうか。

本記事では、品質保証の転換、人間レビューの限界、海外で進む保険市場の変化も踏まえながら、AIエージェント導入前に設計すべき5つの領域と、経営として先に答えるべき3つの問いを整理します。

1. 品質保証の転換：「AIは自信を持って間違える」を前提にする

従来のソフトウェアの品質保証は、少なくとも同じ入力に対して同じ結果を期待しやすく、仕様・テスト・再現性を軸に品質を確認する考え方に立っていました。

ISACAは2025年12月のレビューで、「ハルシネーションは『癖』ではなく安全リスクである。すべての高インパクトなAIシステムは『時に自信を持って間違える』という前提で設計すべきだ」と指摘しています。

複数の研究やレビューで、AIは誤っている場合でも、確信的・権威的に見える表現を取りうることが問題視されています。誤りであっても確信的に見える——この特性が、品質保証を根本から変える必要がある理由です。

以下の図は、従来の品質保証とAI運用時の品質保証の違いを示しています。

IBMの2026年1月の論考は、この転換を実務に落とすフレームワークとして、精度・ドリフト・コンテキストの関連性・コストといったメトリクスの追跡、推論トレースの即時キャプチャ、プロダクション前のストレステストを推奨しています。

品質保証はモデル評価だけで完結しません。どの出力を監視対象にするか、どの異常を運用上のインシデントとみなすかまで含めて設計する必要があります。

2. 人間レビューの落とし穴：オートメーションバイアス

「AIの出力を人間がチェックすれば安心」——この考え方にも限界があります。

AI & Society誌に2025年7月に掲載されたシステマティックレビュー（Romeo & Conti, 2025）は、35の査読済み研究をレビューした結果、説明可能AI（XAI）や透明性メカニズムは、過度に技術的な説明や逆に単純すぎる説明の場合、特にAIリテラシーの低い実務者において誤った信頼を強化する可能性があると結論づけています。説明を増やしても、判断の正確性が向上するとは限らないという知見は、レビュー体制の設計にとって重要な示唆です。

European Journal of Risk Regulationに2025年7月に掲載された論文は、EU AI ActのArticle 14(4)(b)がオートメーションバイアスに明示的に言及していると分析しています。これはEUのハイリスクAIシステムを前提とした規制上の文脈ですが、日本企業にとっても、人間レビューを単なる形式的承認にしないための設計論として参考になります。法規制が人間レビューの限界を認識し始めているということは、企業側もレビューの設計（頻度、方法、レビュアーの選定とトレーニング、AIの確信度に応じた振り分けルール等）まで踏み込む必要があることを意味しています。

3. 海外で進む保険市場の再編：日本でも運用統制と文書化の重要性は高まっている

保険業界の動きは、AIリスクの性質を端的に映し出しています。

保険業界の動きは、AIリスクが既存の保険商品では整理しにくいリスクとして扱われ始めていることを示しています。ただし、以下で紹介する動きは主に米英など海外市場の事例です。日本でも生成AIリスクを対象にした保険商品は登場していますが、現時点で、既存保険からAIリスクを広く除外する動きが一般化しているとまでは言い切れません。

海外では、保険会社がAI関連の損失を既存保険の対象から切り分けようとする動きと、AI固有のリスクを対象にした新しい保険商品の開発が並行して進んでいます。Harvard Law School Forum on Corporate Governanceに掲載されたHunton Andrews Kurthの分析の分析によれば、保険会社はAI関連の損失が既存の保険でカバーされることを懸念し、AI固有の除外条項の導入を進めています。同事務所の別の記事によると、Berkleyは初の「絶対的（Absolute）」AI除外条項を導入しました。

一方で、Hunton Andrews Kurthの報告によれば、Armilla Insurance ServicesによるAI責任保険は、2025年春にLloyd'sの保険会社による引受商品として報じられました。ハルシネーション、モデル性能の劣化、アルゴリズムの故障といったAI固有のリスクをカバーする内容です。

注目すべきは、少なくとも保険引受や補償範囲の議論において、運用統制や文書化の成熟度が従来以上に重視される方向にあるとの見方が出ている点です。

日本でも、生成AIの利用に伴う知的財産権侵害、情報漏えい、ハルシネーションによる名誉毀損等を対象にした保険商品は登場しています。ただし、現時点では、海外で見られるような広範なAI除外条項やAI責任保険市場の本格的な再編が、日本で一般化しているとまでは言えません。だからこそ日本企業にとって重要なのは、「保険で何とかする」ことではなく、保険やコンプライアンスの検討に耐えうる運用統制・ログ・文書化を先に整えておくことです。

4. ガバナンスの構築：6つの柱

ここまでの品質保証・人間レビュー・保険の動向は、いずれも同じ方向を指しています。AIエージェントの運用における最大のリスクは、技術の不完全さよりも、ガバナンスが未設計であることです。

Mayer Brownが2026年2月に公表した論考をもとに整理すると、AIガバナンスの実務フレームワークは大きく6つの構成要素に分けられます。以下の図はそれを視覚化したものです。

同論考が特に強調しているのは文書化の重要性です。規制当局の調査において監査可能な記録を保持していることは、組織が合理的に行動したことを示す助けになります。逆にこのような文書がなければ、防御力が大きく低下します。

5. 実務で設計すべき5つの領域

経営として先に決めるべきなのは、どの業務に、どの権限まで委譲するのか、誰が例外時のオーナーになるのか、そして失敗コストをどこまで許容するのかです。これらが曖昧なままPoCを進めると、実装の成否以前に、導入判断そのものがぶれ始めます。

また、責任分解は組織論や契約論だけで完結しません。とりわけ、どの入出力を監査対象にするか、どの情報を遮断・マスキングするか、どのモデル利用を許可するか、どの操作を人間承認に戻すか、そして異常時の推論経路をどこまで再構成可能にするかは、プラットフォーム設計と運用設計の問題でもあります。

以下の図は、導入前に設計しておくべき5つの領域を整理したものです。

第一は権限設計
エージェントに何をさせ、何をさせないかを明示的に定義することが出発点です。第1回で見たLemkinのケースが示す通り、「やってはいけない期間にやってはいけないことをやる」リスクは、権限設計の不備から生まれます。

第二は、トレーサビリティの確保
第2回で見たように、判断の連鎖を事後的に再構成できなければ、原因分析も責任分解もできません。IBMが推奨する「推論トレースの即時キャプチャ」は、この要件に対応する実務的なアプローチの一つです。

第三は品質モニタリングの設計
ISACAが指摘する通り、「AIは自信を持って間違える」という前提に立ち、定期ベンチマーク、サンプリング検査、閾値アラート、フォールバック手順まで含めた設計が求められます。

第四はステークホルダー間の責任分界の契約化
第2回で整理したキルスイッチ条項・シャドウモード条項・再トレーニングウィンドウ条項・寄与過失の枠組みなど、先進的な契約実務で議論・採用が進みつつあるAI固有の論点を、自社の導入に合わせて契約に組み込みます。

第五は保険・コンプライアンスとの接続
保険市場でAI固有のリスク評価が始まりつつある以上、運用統制や文書化の成熟度が保険の議論に影響し得ます。日本ではAI法やAI事業者ガイドライン、金融分野では金融庁のAIディスカッションペーパー等を踏まえつつ、EU AI Act、米国各州法、業界固有の規制への対応を契約・運用に組み込んでおくことが重要です。

経営として先に答えるべき3つの問い

AIエージェント導入を検討する企業は、少なくとも三つの問いに先に答えておく必要があります。第一に、その業務は誤作動が起きたときにどこまで損失を許容できるのか。第二に、AIに委譲する権限の境界はどこに置くのか。第三に、事故発生時に原因を追跡し、社内外に説明できる状態を作れているのか。

この三つが曖昧なままでは、モデル選定やPoCの精度がどれほど高くても、導入は途中で止まりやすくなります。

設計で終わらず、運用に埋め込むまでが勝負

設計書が存在していても、権限設定が曖昧で、ログが取れておらず、レビュー体制が回らず、現場教育が行われていなければ、ガバナンスは実質的に存在しないのと同じです。

AIエージェント導入の成否は、設計の有無ではなく、設計が運用に埋め込まれているかどうかで決まります。

シリーズのまとめ：AI導入はツール導入ではなく、責任と統制の設計である

全3回を通じて見てきたように、AIエージェントの導入は、モデル性能の評価だけでは完結しません。

第1回では、実際に起きた事故から、AIの問題が技術の不完全さではなく設計の不在にあることを見ました。第2回では、法務・契約・組織の観点から、責任分解がなぜ難しいのか、そしてその難しさをどう契約と運用で補うかを整理しました。第3回では、品質保証の転換、人間レビューの限界、保険市場の再編を踏まえ、実務で先に設計すべき5つの領域と、経営として答えるべき3つの問いを示しました。

AIエージェントの問題は「AIが賢いかどうか」だけではありません。権限設計、監査可能性、契約、運用統制、責任分解をどう設計するかにあります。AIエージェントの導入は、もはや単なるPoCではなく、権限設計・監査可能性・契約・運用統制を含む業務設計そのものです。

技術実装とガバナンス設計を分けずに考えることが、これからのAI導入では重要になるでしょう。

構想から運用定着までQualitegが伴走できる領域

今回は、AI導入を止めないために、実務で先に設計すべきことを整理しました。品質保証の転換、人間レビューの限界、保険市場の変化を踏まえると、AIエージェント導入はもはや単なるPoCではなく、構想・設計・統制・運用まで含めた業務設計だということが見えてきます。

特に重要なのは、権限設計、トレーサビリティ、品質モニタリング、契約上の責任分界、保険・コンプライアンス接続を、ばらばらの論点としてではなく、一つの導入アーキテクチャとしてつなげて考えることです。設計書があるだけでは足りず、それが運用に埋め込まれてはじめて、AIは「試す」段階から「事業に載せる」段階へ進みます。

ここまでのシリーズを通じて見てきた論点は、まさにそのために事前に設計しておくべきものです。

当社では、自社AIプラットフォームの開発・運用で培った実装知見と、AI Transformation・BPR・新規事業開発を含む戦略／業務コンサルティングの両面から、AI導入を「試す」段階で終わらせず、「事業に載せる」ための構想・設計・実装・運用定着まで一気通貫でご支援しています。

AIエージェントの導入では、モデル選定やPoCだけでなく、業務プロセスの再設計、権限設計、監査可能性、情報管理、品質管理、ROIの可視化までを接続して考えることが重要です。Qualitegは、戦略と技術を分断しない体制で、こうした課題に向き合います。

ご関心をお持ちの方は、ぜひお気軽にご相談くださいませ

初期構想の整理、ガバナンス設計、実行基盤の検討、導入後の運用定着まで、課題に応じてご一緒します。

お問い合わせ先

https://qualiteg.com/contact?inquiry=consulting_business

こんにちは、
今回は、主要LLMプロバイダー( Claude / GPT /Gemini/Grok)のAPI料金表 　をまとめてみました。（2026年5月13日時点）

プロバイダ別 料金一覧

まずは各社の現行ラインナップを縦に並べた一覧をご紹介します。価格はすべて per 1M tokens、円表記は 1ドル=160円換算です。

Anthropic(Claude)

Batch API: 全モデル50%オフ(Fast Mode を除く)。

出典: Anthropic 公式 Pricing ページ

OpenAI(GPT)

Batch API: 50%オフ。

出典: OpenAI 公式 API Pricing ページ

xAI(Grok)

※ xAIの廃止告知では grok-4.20-non-reasoning と短縮されていますが、価格表の正式IDは grok-4.20-0309-non-reasoning です。 Batch API: 20〜50%オフ(モデル・トークン種別により異なります)。

出典: xAI 公式 Pricing ページ / xAI モデル廃止予定(2026/5/15)

Google(Gemini)

Batch API: 50%オフ。Pro系はキャッシュストレージ料 $4.50(¥720) / 1M tokens / 時、Flash系は $1.00(¥160) / 1M tokens / 時が別途かかります。

出典: Google AI 公式 Gemini API Pricing ページ / Gemini 3.1 Pro Preview モデルページ

ざっくりまとめ

• 主要フラグシップ級モデルの中では、xAI の Grok 4.3 が $1.25(¥200) / $2.50(¥400) と非常に低単価です。
• Gemini 3.1 Pro Preview は $2.00(¥320) / $12.00(¥1,920) から利用できますが、200k tokens を超えると $4.00(¥640) / $18.00(¥2,880) に上がります。入力上限は約100万トークン(2Mではありません)です。
• Claude Opus 4.7 は $5.00(¥800) / $25.00(¥4,000)、GPT-5.5 は短コンテキストで $5.00(¥800) / $30.00(¥4,800) と、価格帯はほぼ同等です。ただし、長コンテキスト・キャッシュ・ツール利用で実効コストは変わります。
• Batch API は OpenAI / Anthropic / Google は概ね50%割引、xAI は20〜50%割引(モデル・トークン種別により異なります)です。
• プロンプトキャッシュは大きなコスト削減手段ですが、書き込み単価・保存料・ヒット率次第で実効削減率は変わります。

AI APIの料金は毎月のように動いています。ここ半年で起きたことを整理しますと、Anthropicは Opus 4.7 を発表(価格は据え置きですが、新トークナイザで実効値上げの可能性があります)、OpenAI は GPT-5.5 をリリース、xAI は Grok 4.3 を4月末に投入、Google は Gemini 3.1 Pro Preview を提供、という状況です。本記事では各社の 公式ドキュメント を直接確認し、2026年5月13日時点の生きた価格表をまとめました。

通貨換算は 1ドル = 160円 で統一しています。料金表記はドル価格の下に円換算をカッコ書きで併記する形式です(例: $5.00 の下に (¥800))。

⚠️ 重要な注意事項本記事の対象は 主要なテキスト生成API料金 です。画像生成、音声、動画、Enterprise個別契約、リージョン別の細かな加算、Flex / Priority などの上位処理層は、必要に応じて触れる程度にとどめます。価格はすべて2026年5月13日時点の公式ドキュメントに基づいています。実運用時には必ず最新の公式ページでご確認ください。xAI: 2026年5月15日 12:00 PT に grok-4-1-fast-reasoning、grok-4-1-fast-non-reasoning、grok-4-fast-*、grok-4-0709、grok-3 などが廃止予定 です。本記事の表には歴史的比較として旧モデルも掲載していますが、新規採用はおすすめしません。Gemini 3.1 Pro Preview / Gemini 3 Flash Preview は Preview ステータスです。仕様・価格が変動する可能性があります。「品質」「最強」のような評価は本記事では扱いません。価格のみを公式情報ベースで提示します。

フラグシップモデル料金比較

※ xAIの廃止告知ページでは、移行先として grok-4.20-non-reasoning と短縮表記されていますが、価格表上の正式IDは grok-4.20-0309-non-reasoning です。API実装時には、価格表のIDをお使いください。

観察ポイント

• 公式価格表のみで比較すると、フラグシップ級の中では Grok 4.3 / 4.20系が最も低単価です。
• コンテキストウィンドウ最大は xAI Grok 4.20系の 2M tokens です。Gemini 3.1 Pro Preview は約1Mトークンが入力上限であり、200kを超えると単価が上がる二段階構造になっています。
• GPT-5.5 は短/長コンテキストで 入力2倍、出力1.5倍に分岐します。
• Claude Opus 4.7 は表示価格こそ Opus 4.6 と同じですが、新トークナイザにより同じ固定テキストでも最大35%多くトークン化されうる、と公式が明記しています。実効単価は上昇する可能性があります。

ハイエンド・推論特化モデル

OpenAIのProモデルは入力だけで $30(¥4,800)/MTok、出力は $180(¥28,800)/MTok です。1Mトークン使い切ると 約 33,600円(出力中心の場合)に達します。なお、Anthropic の Fast Mode は Claude Opus 4.6 / 4.7 専用の beta / research preview で、6倍料金かつ Batch API との併用はできません。

中位モデル(Sonnet / mini / Flash クラス)

低価格・小型モデル(Haiku / nano / Lite クラス)

Grok 4.1 Fast 系は本記事公開2日後(2026年5月15日 12:00 PT)に廃止予定 です。新規採用はおすすめしません。xAI公式の移行先は、reasoning 系が grok-4.3、non-reasoning 系が grok-4.20-0309-non-reasoning です。

出力/入力比の比較

「出力料金は入力の5〜6倍」という業界通念は、必ずしも全社共通ではありません。

xAIだけが出力倍率を低く設定している点は、構造的な差として重要です。出力中心のワークロード(コード生成、長文生成、推論ループ)では、この差が累積していきます。

1問あたりの実コスト試算

入力1,000トークン + 出力1,000トークン(チャット1往復相当)で計算しました。

全社共通の割引・コスト削減手段

1. Batch API

非同期で24時間以内に処理する代わりに割引が適用されます。

xAIは「一律50%」ではなく、20〜50% と公式ドキュメントに明記されています。予算試算時にはご注意ください。

2. プロンプトキャッシュ

ただし、以下も加味する必要があります:

• キャッシュ書き込みコスト(Anthropicは1.25x〜2xの書き込み料が発生します)
• キャッシュ保存料(Geminiは $1〜4.50(¥160〜720) / 1M tokens / 時)
• キャッシュヒット率(プロンプト設計次第で変わります)

3. ツール利用は別課金

公式ドキュメントによりますと、サーバーサイドツールの多くはトークン料とは別建てで請求されます。

エージェント型ワークフローでは、これらが累積していきますので、トークン単価だけで比較すると実コストを見誤ってしまいます。

各社の戦略的ポジション(筆者の整理)

以下は公式価格表から読み取れる構造的傾向であり、モデル品質の評価ではありません。

Anthropic

Claude Opus 4.7 / Sonnet 4.6 / Haiku 4.5 の3層構成です。価格は安定していますが、Opus 4.7の新トークナイザで実効値上げが起きうる点にはご注意ください。1Mトークンコンテキストを標準価格で提供しています。Fast Mode($30(¥4,800)/$150(¥24,000))という超高速・高価格オプション(Opus専用、6倍料金)も用意されています。

OpenAI

GPT-5.5 が最新フラグシップです。短コンテキスト($5(¥800)/$30(¥4,800))と長コンテキスト($10(¥1,600)/$45(¥7,200))で価格が分岐する、独特な体系を採用しています。Pro版は別格の値段設定です。nanoモデル($0.20(¥32)/$1.25(¥200))で低価格帯もカバーされています。

xAI

Grok 4.3 が現行フラグシップ($1.25(¥200)/$2.50(¥400)、1Mコンテキスト)です。Grok 4.20系(grok-4.20-0309-reasoning 等)は2Mトークンコンテキストを同価格で提供しており、長文用途では4.3より有利な場合もあります。出力倍率を低く設定している点が、他社とは異なります。一方、2026年5月15日に旧Fast系列モデルが廃止されるため、移行作業が発生する点にもご注意ください。

Google

Gemini 3.1 Pro Preview が最新版(Previewステータス)です。$2(¥320)/$12(¥1,920) で約1Mトークンの入力に対応し、>200kトークンで $4(¥640)/$18(¥2,880) への二段階構造になっています。Flash系列(Gemini 3.1 Flash-Lite、Gemini 2.5 Flash-Lite)は業界最安値クラスです。AI Studioで無料試用が可能ですが、2026年4月以降はPro系列が有料のみになりました。

用途別の参考(価格観点のみ)

価格は四半期ごとに動きます。本番投入の前には、必ず公式ドキュメントで最終確認をなさってください。

ソース(2026年5月13日確認)

• Anthropic: platform.claude.com/docs/en/about-claude/pricing
• OpenAI: developers.openai.com/api/docs/pricing
• xAI 価格: docs.x.ai/developers/pricing
• xAI モデル廃止予定: docs.x.ai/developers/migration/may-15-deprecation
• Google: ai.google.dev/gemini-api/docs/pricing

本記事の価格は、2026年5月13日時点の公式ドキュメントに基づいています。為替は1ドル160円で固定計算しているため、実際の請求額は当日のレートと支払い手段によって変動します。Batch API、プロンプトキャッシュ、データレジデンシー、ツール利用料、リージョナルエンドポイント加算により、実効単価はさらに変化します。「品質」「最強」のような評価は本記事の射程外であり、ベンチマーク・実測・用途適合性は別途評価する必要があります。

それではまた次回お会いしましょう！

こんにちは！

コーディングエージェントシリーズ、ついに最終回です！

2026年に入り、Claude Code、Cursor 3、GitHub Copilot Coding Agentはいずれも、単なるコード補完やチャット型支援を超え、複数エージェントを使った開発ワークフローへ進化しつつあります。本稿では、AIコーディングエージェントの最新動向を、Claude CodeのAuto Memory / Subagents、Cursor 3のAgents Window、GitHub CopilotのCoding Agent、そしてSWE-benchの読み方まで含めて整理します。

第1回では、2025年12月時点で百花繚乱状態にあったAIコーディングエージェントの全体像を俯瞰し、商用からOSSまで20以上のツールを「CLIベース」「IDE統合型」「AI特化IDE型」「自律型」の4つのカテゴリに整理しました。

第2回では、Claude Code・Codex CLI・Aiderを詳細比較したうえで、現在のコーディングエージェントが共通して抱える構造的課題——コンテキストウィンドウの限界、セッション間の記憶喪失、ベンチマークと実世界のギャップ——を、Claude Codeの「4つの構造的問題」として整理しました。

そして第2回の最後では、最終回でMicrosoftのAmplifierを取り上げ、これらの課題への解決アプローチを詳しく見ていく、と予告していました。

……のですが。

はじめに：予告したことと、ちがう話をします

正直にお話しします。

第2回を書いてから、ほんの数ヶ月で、コーディングエージェントを取り巻く景色がガラッと変わってしまいました。

第2回で「Claude Codeの4つの構造的問題」として整理した課題に対して、Claude Code自身の進化によって、対応が急速に進みつつあるのです。

これは予想外でした。

Amplifierという「外部からの解決策」を期待していた話が、Anthropic自身の手によって内部から対処されはじめた、という状況です。それも、わずか数ヶ月で。

そこで本記事では、当初の予告から大幅に内容を変更し、以下の構成でお届けすることにしました。

• まず、第2回で挙げた4つの課題に対して、どのような対応が進んでいるのかを見ていきます
• 次に、Cursor・GitHub Copilotといった競合の進化を概観します
• そのうえで、Amplifierが今、どのような位置づけにあるのかを改めて評価します
• 最後に、ベンチマークの読み方（再訪）と、開発者の役割が変わりつつある現実について考えます

第2回の予告を期待してくださった方には申し訳ないのですが、2026年5月時点で本当に重要なのは「Amplifierがどう課題を解決するか」ではなく、業界全体が次のステージに入りつつあるという事実だと判断しました。

それでは、いってみましょう！

シリーズ構成（再掲）

3-1. 第2回の課題、Claude Codeはどう対応しているのか

第2回でまとめた「4つの構造的問題」を、もう一度確認してみましょう。

ひとつずつ見ていきます。

3-1-1. 記憶喪失問題への対応：Auto Memory

第2回で「毎日昨日のことを全部わすれるエンジニア」と表現したClaude Codeの記憶喪失問題。

これに対するAnthropicの回答のひとつが、Auto Memory（v2.1.59〜）です。

公式ドキュメントによれば、Auto Memoryは、Claude Codeが作業中に自動で「メモを取る」機能です。デバッグのパターン、ビルドコマンド、アーキテクチャ上の決定、ユーザーの好み——こうした情報を、プロジェクト単位のauto memory directoryに蓄積していきます。MEMORY.mdはその索引として機能し、セッション開始時には最初の200行または25KBまでが読み込まれます。

なお、auto memoryはmachine-localで、同じGitリポジトリ内のworktreeやサブディレクトリで共有される設計です。

また、GitHub Issueやコミュニティ上では、蓄積されたメモリを自動で整理・統合する実験的な挙動（Auto Dreamと呼ばれることがある）も報告されています。ただし、これについては公式ドキュメント上で安定機能として整理されているわけではないため、本稿では詳細な説明は控えます。

ポイント： 第2回で指摘した「CLAUDE.mdは手動管理」というジレンマに対して、自動でメモリを蓄積する仕組みが整備されつつあります。「記憶喪失が完全に解決した」とまでは言えませんが、永続記憶に向けた機能が急速に整備されているのは確かです。

3-1-2. コンテキスト溢れ問題への対応：要約・圧縮の仕組み

第2回で「約50回のツール使用で200Kトークンの限界に達する」と書いたコンテキスト問題。

これに対しては、Claude Codeには要約・圧縮の仕組みが整備されています。

公式ドキュメントによれば、特にSkillsについては、compaction（圧縮）後も直近のskill呼び出しが一定範囲で再付与される設計になっています。各skillは最初の5,000トークン、合計25,000トークンの予算で保持されます。

また、/compact コマンドでユーザーが任意のタイミングで圧縮を走らせることもできます。

ポイント： 内部の圧縮パイプラインの詳細は公式に明示されていませんが、「コンテキストが大きくなっても、重要な情報を保持しながら圧縮する仕組み」が整備されつつあることは確かです。第2回で紹介した「約50回で限界」という状況は、改善に向かっています。

3-1-3. 単一エージェント問題への対応：Subagents

第2回で「設計もデバッグも全て1人」と書いた単一エージェント問題。

これに対しては、Claude Codeは Subagents（サブエージェント） という機能で対応しています。

公式ドキュメントによれば、Subagentsは、メインのClaude Codeセッションから独立した「専門エージェント」を呼び出す仕組みです。それぞれが独立したコンテキストウィンドウを持ち、メインセッションのコンテキストを汚染することなく、特定のタスクに集中できます。

実装としては、.claude/agents/ ディレクトリに、エージェント定義をMarkdownで記述します。例えば：

• code-reviewer.md：コードレビュー専門のサブエージェント
• test-writer.md：テストコード生成に特化したサブエージェント
• db-migrator.md：データベースマイグレーション専門

メインのClaude Codeは、タスクの性質を見て適切なサブエージェントを呼び出し、結果だけを受け取ります。

さらに、実験的機能として Agent Teams（環境変数 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 で有効化）も登場しています。これは、複数のサブエージェントがチームとして協調動作する、より野心的な仕組みです。

ただし、Agent Teamsは公式にもexperimentalと位置づけられており、デフォルトでは無効化されています。セッション再開、タスク調整、終了処理などに既知の制限があるため、現時点では本番開発フローに無条件で組み込むというより、研究・検証用途から使い始めるのが現実的です。

3-1-4. 単線試行錯誤問題への対応：Worktrees統合

第2回で「並行して試せない」と指摘した問題。

Claude Codeはこれに対して、Git Worktrees統合 で対応しています。

Claude Codeでは、Git worktreeを使って複数の作業ブランチを分ける運用が紹介されています。サブエージェントが独立したworktreeで作業できるため、コンフリクトを起こさずに複数のアプローチを並列で試すことができます。

これは、第2回で示唆した「同じ問題に対して複数の解法を並行して試したい」というニーズに対応する機能です。

3-1-5. まとめ：課題は「解決」ではなく「対応が進んでいる」

ここまで見てきたように、第2回で挙げた課題は、完全に消えたわけではありません。

ただし、Claude Code本体にAuto Memory、Subagents、Worktrees、Skills、Agent Teamsといった仕組みが入り、少なくとも**「外部ツールで補うしかなかった課題」の多くに、本体側から対処が始まっている**のは事実です。

3-1-6. その他の進化（参考）

ついでに、2026年に入ってからのClaude Codeの主な追加機能を並べておきます。

• Plugins / Skills / Hooks：拡張性の大幅向上
• MCP統合：外部ツールとの連携（Model Context Protocol）
• Custom Themes：/theme コマンドでカスタマイズ
• Vim Mode：v/Vでvisualモード
• VS Code拡張機能（ベータ）：2026年1月、ネイティブ統合
• Push Notifications：Remote Control経由でモバイル通知

第2回の頃の「Claude Codeはターミナル専用のミニマルなCLI」というイメージとは、もはや別物と言っていいくらい機能が増えています。

3-2. 競合も止まらない：Cursor 3とGitHub Copilotの進化

進化していたのはClaude Codeだけではありません。

第2回でも触れたCursorとGitHub Copilotも、この数ヶ月で大きな転換を遂げています。

3-2-1. Cursor 3：エージェント中心のインターフェースへ

2026年4月2日、Cursorは Cursor 3 をリリースしました。

公式ブログによれば、このリリースに添えられたCEO Michael Truell氏のメッセージは、なかなか挑発的なものでした。

我々は、ソフトウェア開発の第3の時代に入りつつある。 第1の時代は手動でファイルを編集する時代。 第2の時代はAIエージェントとペアで作業する時代。 そして第3の時代は、自律的に動くエージェントの艦隊（fleets of agents）が、改善を出荷し続ける時代である。

Cursor 3では、この「艦隊」を運用するためのインターフェース 「Agents Window」 が中心に据えられました。

公式に確認できる主な特徴：

• Agents Window：エージェント中心のインターフェース
• Local / Cloud Agents：ローカルとクラウドの両方でエージェントを実行
• Composer 2：Cursor独自のフロンティアコーディングモデル
• 統合ブラウザ：開発中のプレビューをエディタ内で確認
• Marketplace Plugins：プラグインによる拡張

「ペアプログラミング」から「小さなエンジニアリングチームのオーケストレーション」へ、というのがCursor 3のメッセージです。

第2回で紹介した「Cursor＝AI特化IDE」というカテゴリ分類は、もはや古い視点になりつつあります。Cursorは今や、エージェント艦隊運用のためのワークスペース になろうとしています。

3-2-2. GitHub Copilot：Coding AgentからCloud Agentへ

GitHub Copilotも、もはや「コード補完ツール」ではなくなりました。

Copilotの進化を時系列で整理すると：

• 2025年9月：Coding AgentがGA（GitHub Issueを割り当てると、Copilotが自律的に分析・実装・PR作成まで行う）
• 2026年1月：Copilot Memory（agentic memory）がpublic preview（リポジトリの有用な情報を自動推定・保存）
• 2026年：Agent Skills、Custom Agents、複数モデル対応（GPT、Claude、Gemini）

特に Coding Agent（現在はCloud Agentとも呼ばれる）は注目に値します。

GitHub上のIssueに対してCopilotをアサインすると、Copilotは以下を完全に非同期で実行します：

1. Issueの内容とリポジトリのコンテキストを分析
2. 実装計画を立案
3. 別ブランチでコードを変更
4. テストを実行
5. PRを作成し、サマリを添える

開発者は「Issueをアサインして、後で戻ってきてPRをレビューする」だけ。第2回で示唆した「自律型エージェント」の世界が、すでにGitHub上の開発ワークフローに組み込まれはじめています。

3-2-3. つまり、業界全体が動いている

Anthropic、Cursor、GitHubの3社の動きを並べてみると、進む方向はかなりはっきりしています。

見ている方向はかなり近いです。単一エージェントで頑張るのではなく、記憶を持たせ、役割を分け、並列に走らせ、最後は人間がレビューする。この形に、主要ツールが一斉に寄ってきています。

OSSエコシステムも同様で、OpenHands、Cline、Aiderなどが、それぞれの方向性で並列処理・専門エージェント・永続記憶を実装しはじめています。OpenHandsは72,000 stars超を記録しており、OSSコーディングエージェントの中でも特に注目を集めています。

3-3. では、Amplifierは何だったのか

ここで本シリーズで取り上げる予定だった、MicrosoftのGitHubリポジトリで公開されている研究プロジェクト Amplifier に戻ります。

正直なところ、本記事の執筆時点で、Amplifierの位置づけはかなり微妙なものになっています。

3-3-1. Amplifierの当初の魅力

Amplifierは、もともと「Claude Codeの構造的課題を、外側から補完する」というポジションで魅力的でした。

• 専門化されたエージェント群
• Knowledge Graph的な永続記憶のアプローチ
• マイクロカーネル設計（オーケストレーターを差し替え可能）

これらは、第2回で挙げた4つの課題に対する、まさに「あるべき姿」のひとつでした。

3-3-2. しかし、商用ツールが追いついた

ところが、ここまで見てきたとおり、Amplifierが提案していた解決策の多くは、Claude Code・Cursor・GitHub Copilotといった商用ツールが、本体機能として実装しはじめました。

• 専門エージェント → Claude Code Subagents、Copilot Custom Agents
• 永続記憶 → Auto Memory、Copilot Memory
• 並列実行 → Worktrees統合、Copilot Coding Agent
• 拡張性 → Plugins / Skills / Hooks、MCP統合

商用ツール側がこれだけ進化してしまうと、「Amplifierでなければできないこと」を見つけるのは、難しくなりつつあります。

3-3-3. Amplifier開発者自身の認識

実は、これはAmplifier開発者のBrian Krabach氏自身が、最初から述べていたことでもあります。

Krabach氏のMedium記事で、こう書いています

"This is not a launch post for Microsoft release."（これはMicrosoftのリリース告知ではない） "research-stage development environment"（研究段階の開発環境である） "Claude today, something else tomorrow. The value is the knowledge, patterns, and automation — not any specific model."（今日はClaude、明日は別のもの。価値はナレッジ、パターン、自動化にあって、特定のモデルにはない）

つまり、Amplifierは最初から 「特定のモデル・ツールに依存しない、研究フレームワーク」 として位置づけられていました。

商用ツールの進化が早すぎて、結果的に「研究フレームワーク」としての側面がより色濃くなった、というのが現状の見方として妥当でしょう。

3-3-4. それでもAmplifierが意味を持つケース

「ではもうAmplifierには価値がないのか」というと、そうとも言い切れません。以下のようなケースでは、依然として検討に値する選択肢です。

ただし、コミュニティの評価は必ずしも好意的なものばかりではありません。「アイデアは良い、だが実用にはまだ研究途上」という評価が、もっとも実態に近いところでしょう。

3-3-5. Amplifierの本当の役割

それでもなお、Amplifierには重要な役割があると考えています。

それは、「商用ツールが採用する前のアイデアを、先に試す研究プラットフォーム」 としての役割です。

実際、Amplifierが提案していた多くの概念——専門エージェントの組み合わせ、永続記憶のアプローチ、マイクロカーネル設計——は、形を変えながら商用ツールに取り込まれていきました。OSSの研究プロジェクトが、業界の方向性を先取りして示すという、健全な役割を果たしてきたとも言えます。

つまり、Amplifierは「Claude Codeの代替」ではなく、「次にClaude Codeが向かう方向を示す実験場」 として見るのが、いちばんしっくりくる位置づけかもしれません。

3-4. ベンチマークの読み方（再訪）

第2回で、SWE-bench Proの結果について「従来のSWE-bench Verifiedで70%以上のスコアを達成していたモデルが、23%程度まで性能が低下する」と紹介しました。

この問題は、2026年5月時点でも依然として重要です。

3-4-1. 2026年5月時点の主要なベンチマーク数値

公式に確認できた数値を整理します。

Claude Opus 4.7のSWE-bench Verified 87.6%は、かなり高い数値です。これだけ見ると「もう実用上の問題はないのでは」と感じます。

3-4-2. しかし、memorization懸念は残る

ところが、SWE-bench系の評価には、memorization（記憶）/ contamination（汚染）の懸念 が指摘されています。

AnthropicのProject Glasswing発表でも、OpenAIのGPT-5.5発表でも、評価結果を読む際にこの点が注記されています。

実際、より厳格なベンチマーク（SWE-bench Pro）では、スコアが大幅に低下します：

• Claude Mythos Preview：Verified 93.9% → Pro 77.8%
• Claude Opus 4.7：Verified 87.6% → Pro 64.3%
• GPT-5.5：Pro 58.6%

また、実務では公開OSSベンチマークとは異なる制約が加わるため、プライベートな商用コードベースで同等の性能が出るとは限りません。

つまり、公開ベンチマークの数値は有用な参考値ではあるが、自社コードベースでの性能をそのまま保証するものではない、ということです。

3-4-3. 何を信じるべきか

ベンチマークの数字は、ツール選定の参考にはなりますが、自社のコードベースで、自社のタスクで実測すること 以外に、本当の性能を知る方法はありません。

実務的なアドバイスとしては、以下のようなものになります：

• ベンチマークは「上限の指標」として見る（実環境ではこれより低い）
• 自社の代表的タスク3〜5本で、実際に複数ツールを試す
• 「成功率」だけでなく「失敗時の挙動」も評価する（暴走するか、適切に止まるか）
• セキュリティ要件・データ取扱要件と照らし合わせる

ベンチマークが上がっても、実務での「使える/使えない」は別問題である、というのは、2025年12月時点の第1回・第2回から、本質的に変わっていません。

3-5. 開発者の役割は、すでに変わりつつある

ここまでの話を踏まえると、ひとつの大きな構造変化が見えてきます。

それは、開発者の役割が「コーダー」から「エージェント・オーケストレーター」へと変わりつつある、という変化です。

3-5-1. 「コードを書く人」から「エージェントを指揮する人」へ

Cursor 3のキーワード「fleets of agents（エージェントの艦隊）」、GitHub Copilotの「Coding Agent」、Claude Codeの「Subagents + Worktrees」——これらに共通しているのは、人間が複数のエージェントを並列に走らせ、結果をレビュー・統合する という働き方への移行です。

1人の開発者が、複数のエージェントを同時に走らせるような働き方が、一部では現実のものになりつつあります。

3-5-2. これが意味すること

この変化が示唆するものは、いくつかあります。

1つ目は、「タスクの分解能力」の重要性が増したことです。

エージェントを並列に走らせるためには、タスクを「並列に実行できる単位」に分解する必要があります。これは、実装そのものを書く能力よりも、設計・分解・統合の能力が問われる仕事です。

2つ目は、レビューの負担が増えたことです。

エージェントが書いたコードは、人間が書いたコードより 「一見もっともらしいが、微妙にずれている」 ことが多くあります。並列に5本のPRが上がってきたら、それを5本ぶんレビューする必要があります。

3つ目は、コストの感覚が変わることです。

Cursor 3のCloud Agent、GitHub CopilotのCoding Agent、Claude CodeのSubagents——これらは並列度に応じてコストが増えます。「速度を金で買う」という選択が、開発の現場で日常になりつつあります。

3-5-3. それでも変わらないこと

一方で、変わらないことも、はっきりしてきました。

• ベンチマークの数字と、実務での使いやすさは別問題
• 自社コードベースでの実測なしに、ツール選定はできない
• エージェントを「監視なしで走らせる」のは、依然としてリスクが高い
• セキュリティ・プライバシー要件は、ツール選定の前提として効いてくる

ツールが進化しても、「何を作るべきか」を決めるのは人間です。エージェントが書いたコードが「正しいかどうか」を判断するのも、最終的には人間です。

「コードを書く時間が減って、考える時間が増えた」——これは、2026年5月時点でAIコーディングエージェントを使っている多くの開発者が共通して感じていることだと思います。

第3回まとめ

本稿では、当初予告したAmplifier中心の内容から方向を変え、2026年5月時点のコーディングエージェント業界全体を概観しました。

ポイント

• 第2回で挙げた「Claude Codeの4つの構造的問題」に対して、Claude Code自身の進化（Auto Memory、Subagents、Worktrees統合）で対応が進んでいる
• Cursor 3は「エージェントの艦隊」、GitHub Copilotは2025年にCoding AgentをGA化し、業界全体が「エージェント・オーケストレーション」の時代に入りつつある
• Amplifierは「Claude Codeの代替」ではなく、「商用ツールの方向性を先取りする研究プラットフォーム」 として位置づけるのが現実的
• SWE-bench系にはmemorizationの懸念があり、自社コードベースでの実測が不可欠
• 開発者の役割は「コーダー」から「エージェント・オーケストレーター」へと、変わりつつある

シリーズを振り返って

3回にわたってお届けしてきた本シリーズ、いかがでしたでしょうか。

第1回（2025年12月）の時点では、「20以上のツールがあって、どれを選べばいいかわからない」という状況でした。

第2回（2026年1月）では、「ツールの本質的な限界」を整理し、構造的課題を浮き彫りにしました。

そして第3回（2026年5月）では、その課題への対応が想像よりずっと早く進んでおり、業界全体が次のステージに入りつつあることを確認しました。

わずか5ヶ月で、この業界の景色がここまで変わってしまうとは、第1回を書いた時点ではまったく予想していませんでした。

おそらく、この記事を書いている2026年5月の時点での「最新動向」も、半年後には古い情報になっているはずです。それくらい、この分野の進化は速い。

ただ、3回を通して見えてきた本質的なポイントは、おそらく当面変わりません。

• 何を作るべきかを決めるのは、依然として人間である
• エージェントが書いたコードを評価できるのも、依然として人間である
• ベンチマークの数字よりも、自社の実測のほうが信頼できる
• ツールは増え続けるが、本質的な選定基準（自社のコード、要件、運用体制）は変わらない

エージェントの艦隊を指揮する立場に立った今、「何を指揮するか」を考えるのが、開発者にとって、これまで以上に大事な仕事になったような気がしています。

企業でのAIコーディングエージェント導入をご検討の方へ

企業でコーディングエージェントを導入する際には、単に「どのツールが最も賢いか」ではなく、自社コードベースでの成功率、レビュー負荷、セキュリティ要件、権限設計、利用コスト、失敗時の止め方まで含めて評価する必要があります。

Qualitegでは、AIエージェントやLLM活用の実装知見をもとに、ツール選定からPoC設計、社内開発プロセスへの組み込み、運用ルール整備までご支援しています。

ご相談・お問い合わせはこちらから受け付けております

それでは、3部作にお付き合いいただき、ありがとうございました！
またお会いしましょう！

こんにちは！
公式PowerShellインストーラー(irm https://claude.ai/install.ps1 | iex)で Claude Code を入れたのに、claude --version を叩くと「The term 'claude' is not recognized as a name of a cmdlet...」と怒られるときがあります

これは Anthropic 公式 GitHub にも報告されている 既知のバグで、インストーラーが PATH の追加を忘れています。実際にインストール作業をやって詰まったので、最短の解決手順をまとめます。

環境

• Windows 11
• PowerShell 7.x(コードは PowerShell 5.1 / Windows PowerShell でも同じ)
• Anthropic アカウント(Pro / Max / Team / Enterprise いずれか)

前提:Git for Windows を入れておく

Claude Code は Windows ネイティブで動く時、内部で Git Bash を使います。入っていないとインストール後の動作で問題が出るので、先に確認しましょう

git --version

エラーが返るなら winget で入れます

winget install Git.Git --source winget

インストール後は PowerShell を一度閉じて開き直すこと。git が PATH に通ります。

ステップ1:公式インストーラーで Claude Code を入れる

PowerShell(管理者権限は不要)で以下を実行します

irm https://claude.ai/install.ps1 | iex

成功すると以下のようなメッセージが出ます

Setting up Claude Code...
✓ Claude Code successfully installed!
  Version: 2.x.x
  Location: C:\Users\<ユーザー名>\.local\bin\claude.exe

Next: Run claude --help to get started

ここで claude --help を叩きたくなりますが、たぶん動きません。

ステップ2:エラーを確認する

claude --version

claude: The term 'claude' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

このエラーが出たら、原因はほぼ確実に PATH 未追加です。

ステップ3:claude.exe の存在を確認する

念のため、本当にインストールされているかを確認します

Test-Path "$env:USERPROFILE\.local\bin\claude.exe"

True が返ってくれば、ファイルは存在します。あとは PATH に通すだけです。

ステップ4:PATH に追加する

ユーザー環境変数の PATH に ~\.local\bin を永続的に追加します

[Environment]::SetEnvironmentVariable("PATH", "$env:PATH;$env:USERPROFILE\.local\bin", [EnvironmentVariableTarget]::User)

このコマンドは「次回以降のセッションで反映」する設定なので、現在のセッションでも使いたい場合は次のコマンドも実行します

$env:PATH = "$env:PATH;$env:USERPROFILE\.local\bin"

ステップ5:動作確認

claude --version

バージョンが表示されたら成功です。

それでもダメなら、PowerShell のウィンドウを完全に閉じて開き直してください。タブを閉じるだけでは反映されないことがあります。それでもダメなら Windows を再起動。

ステップ6:初回起動と認証

claude

ブラウザが開いて OAuth 認証フローに入ります。Anthropic アカウント(Pro / Max など)でサインインすれば、トークンが ~\.claude\session.json に保存されて、以降は再ログイン不要になります。

トラブルシューティング

Get-Command で実体を確認

PowerShell がどの claude.exe を見ているか確認したい時は、

Get-Command claude | Format-List

複数の場所にインストールされていないかは以下で確認します

Get-Command claude -All

winget 版と公式インストーラー版の併存

winget install Anthropic.ClaudeCode と irm の両方を試している場合、両方インストールされていて古いほうが優先されているケースがあります。これも公式 GitHub に上がっているバグです。

不要なほうを削除

# winget版を消したい場合
winget uninstall Anthropic.ClaudeCode

自己診断コマンド

困ったらこれを叩くと、インストール状態・バージョン・認証・Git・PATH の問題をまとめて検出してくれます

claude doctor

なぜこうなるのか

irm https://claude.ai/install.ps1 | iex は claude.exe を C:\Users\<ユーザー名>\.local\bin\ に配置しますが、このフォルダを PATH に追加する処理が現状のインストーラーに含まれていません。インストーラー自体も「Setup notes」という黄色い警告で気づいてはいるのですが、自動修正してくれないので、ユーザー側で手動対応が必要、というのが現状です。

Anthropic 側の Issue として登録済みなので、いずれ修正されるはずですが、それまでは手動対応する必要があります。

まとめ:最短コマンド集

詰まったとき用に、ここまでの流れをまとめておきます

# 1. インストール
irm https://claude.ai/install.ps1 | iex

# 2. 実体確認
Test-Path "$env:USERPROFILE\.local\bin\claude.exe"

# 3. PATH追加(永続)
[Environment]::SetEnvironmentVariable("PATH", "$env:PATH;$env:USERPROFILE\.local\bin", [EnvironmentVariableTarget]::User)

# 4. PATH追加(現セッション)
$env:PATH = "$env:PATH;$env:USERPROFILE\.local\bin"

# 5. 動作確認
claude --version

これでダメなら PowerShell を閉じて開き直し、それでもダメなら Windows 再起動。ほぼこれで通ります。

こんにちは！
Qualitegプロダクト開発部です！

2026年4月に、AnthropicからClaude Opus 4.7がリリースされました。

今回のアップデートは、単にベンチマークが上がったという話ではありません。命令の解釈の仕方、応答長、ツール呼び出しの頻度、subagentの起動方針まで、モデルの振る舞いそのものが変わっています。

それに伴い、4.6までに作り込んだプロンプトや設定の一部は、外したり再評価したりする必要があります。本記事では、そうした移行時の落とし穴と、4.7時代に合わせた運用作法を、できるだけ実践的にまとめました。

この記事では、まずOpus 4.7で何が変わったのかを確認し、そのうえでClaude Code CLI版とClaude Code Web版でどう使いこなすべきかを見ていきます。 (通常のclaude.aiチャットUIは対象外です。)

なお、けっこう長めの記事になっているので、
頭から通読していただく必要はありません。

下の目次から、気になるところや今すぐ困っているところだけ拾い読みしていただいて大丈夫です。

たとえば「とりあえず4.6から4.7に上げて何が変わるのか知りたい」という方は第1部の3章だけ、

「Claude Code CLIで明日から使える運用ノウハウが欲しい」という方は第2部の8章と9章だけ、

「Web版を試してみたい」という方は第3部だけ、といった読み方を想定して書いています。

困ったときのリファレンスとしても使えるよう、各章は独立して読めるようにしてあるので、ブックマークしておいて必要なときに戻ってきていただくのもおすすめです。

目次

第1部:Claude Opus 4.7とは何か

1. 4.6から4.7への移行で変わるもの
振る舞いの変更9項目とAPIレベルの破壊的変更5項目の概観です。

2. モデルとしてのClaude Opus 4.7
基本仕様、高解像度画像、新トークナイザー、1Mコンテキストの標準価格化を確認します。

3. 振る舞いの変化 — 4.6から4.7で何が変わったのか
命令解釈、応答長、ツール使用、subagent、トーン、進捗報告など、プロンプト再評価が必要な変化を見ます。

4. 補足:Claude Code利用者も知っておきたいMessages API側の破壊的変更
Messages API直接利用時に影響する変更点を、Claude Code利用者の視点で整理します。

5. 新機能
新effortレベル xhigh、task budgets、ファイルベースメモリの改善を見ます。

第2部:Claude Code CLI版で使うOpus 4.7

6. Claude CodeにおけるOpus 4.7の前提
バージョン要件、エイリアス解決、プラン別デフォルトを確認します。

7. Claude Codeの基本操作 — CLIコマンドの使い方一覧
起動・終了、スラッシュコマンド、設定ファイル、環境変数の早見表です。

8. 日常運用のリズム — Claude Codeをふだんどう使うか
初回ターンへの情報集約、Auto Mode、effort切り替えなど、1日の典型的な使い方を見ます。

9. Effort Levelの使い分け
5段階の定義と使い分け、ultrathink の小ワザを見ます。

10. 1Mコンテキストの正確な扱い方
プラン別の可用性、opus[1m] サフィックス、opusplan の落とし穴を確認します。

11. Claude CodeにおけるAdaptive Reasoning
Opus 4.7では無効化できないという仕様と、誘導の方法を見ます。

12. Opus 4.7を最大限引き出すプロンプティング
依頼書スタイル、肯定形の例示、検証機構などのプロンプト設計の原則を見ます。

13. エンタープライズ運用
モデル制限、Default解決の制御、prompt cachingなど、組織展開時のポイントを確認します。

第3部:Claude Code Web版で使うOpus 4.7

14. Claude Code Web版とは何か
ブラウザで動くクラウド実行環境としての立ち位置を、CLI版との違いとともに見ます。

15. Web版を使い始める — GitHub連携と環境設定
GitHub認証、Environment、セットアップスクリプト、ネットワークアクセスを見ます。

16. ターミナルとWeb版を行き来する
--remote と --teleport を使った連続的な作業パターンを見ます。

17. Web版でのセッション運用
セッション永続性、コンテキスト管理、diffレビュー、Auto-fixを確認します。

18. Web版でOpus 4.7を活かすコーディング作法
タスク粒度、Web版仕様の依頼書プロンプト、並列実行、デバッグ作法を見ます。

まとめ

第1部:Claude Opus 4.7とは何か

1. 4.6から4.7への移行で変わるもの

2026年4月16日、AnthropicはClaude Opus 4.7をリリースしました。Anthropic公式が「最も高性能な汎用モデル」と位置づけており、コーディング、長期エージェントワーク、ナレッジワーク、ビジョン、メモリ関連のタスクで前世代を上回る性能を発揮するとされています。

ただし、Opus 4.7への移行は単なる性能アップデートではありません。Anthropic公式のMigration Guideには、Opus 4.6までと同じプロンプトでは想定通りに動かなくなる可能性のある「振る舞いの変更」が9項目、APIレベルの破壊的変更が5項目、明示的に列挙されています。これらを把握せずに切り替えると、「以前は通っていたAPI呼び出しが400エラーで返ってくる」「同じプロンプトなのに応答の品質や長さが変わる」「トークン消費が増えてコストが膨らむ」といったことが起きやすくなります。

第1部では、まずモデルとしてのOpus 4.7の仕様を見ていきます。

↑ 目次に戻る

2. モデルとしてのClaude Opus 4.7

2.1 基本スペック

Claude Opus 4.7の主要スペックは以下の通りです(出典:What's new in Claude Opus 4.7)。

最大出力128kは同期Messages APIにおける値です。Message Batches APIでは、ベータヘッダー(output-300k-2026-03-24)により別枠で最大300kトークン出力に対応します。

トークン単価はOpus 4.6と同等で、価格帯としては据え置きです。Prompt caching、Batch processing、Files API、PDF support、Vision、各種ツール(bash、code execution、computer use、text editor、web search、web fetch、MCP connector、memory)といったAPI・プラットフォーム機能の大枠もOpus 4.6と同等です。

ただし、後述する通り新しいトークナイザーの導入により、同じテキストでも消費トークン数が約1.0〜1.35倍に増える可能性があります。トークン単価が同じだからといって、ワークロード全体のコストが据え置きになるわけではない点には注意が必要です。

2.2 高解像度画像対応の刷新

Claude Opus 4.7は、Claudeモデルとして初めて高解像度画像をネイティブにサポートしました。最大解像度は2576ピクセル / 3.75メガピクセルで、従来の1568ピクセル / 1.15メガピクセルから大幅に拡張されています。

技術的に重要な変更がもう一つあります。モデルが返す座標が実画像のピクセルと1:1で一致するようになった点です。Opus 4.6までは、ポインティングやバウンディングボックス座標を取得した後、表示サイズに合わせたスケール変換を独自に実装する必要がありました。Opus 4.7ではこの変換コードが不要になります。

computer use、スクリーンショット解析、ドキュメント解析、図表分析といった視覚処理中心のワークロードで、実装の簡素化と精度向上の両方が期待できます。

ただしコスト面で注意点があります。フル解像度の画像は、従来モデル比で約3倍のトークンを消費する可能性があります。具体的には1画像あたり最大約4,784トークン(従来は約1,600トークン)まで増加し得ます。視覚中心のワークロードでは、max_tokens の予算とコスト試算をやり直す必要があります。

公式ドキュメントでは、画像の追加解像度が不要なケースでは送信前にダウンサンプリングすることが案内されています。

2.3 新トークナイザーの導入と、コスト試算への影響

Claude Opus 4.7は新しいトークナイザーを採用しています。これは性能改善に寄与している一方、同じテキストでも従来モデルと比べてトークン数が約1.0倍から1.35倍(最大で約35%増)になる可能性があります。増加率はコンテンツの種類によって変動します。

実務では、影響は大きく3つあります。

まず、トークン数の見積もりです。/v1/messages/count_tokens エンドポイントが返すトークン数がOpus 4.6と異なります。クライアント側でトークン数を見積もるロジックや、文字数からトークン数を推定する固定比率を持つコードは、Opus 4.7で再テストが必要です。

次に、max_tokens の設定です。同じプロンプトと出力でも消費トークン数が増える可能性があるため、余裕を持たせた設定が望ましいです。コンテキスト圧縮のトリガー条件も同様に再調整が必要です。

最後に、月次コストの試算です。トークン単価は据え置きですが、同じワークロードを処理する際の総トークン数が増える可能性があるため、コスト見積もりはOpus 4.7ベースで再計算するのが適切です。

コスト管理の手段としては、プロンプトの工夫(簡潔さの指示など)、task_budget の活用(後述)、effort パラメータの調整の併用が基本になります。これらは性能とのトレードオフを伴うため、使い方によって設定を変える必要があります。

2.4 1Mコンテキストの標準価格化が持つ意味

Opus 4.7は1Mトークンのコンテキストウィンドウを標準API価格で提供します。200Kトークンを超えるリクエストに対する追加料金(long-context premium)は存在しません。

これはOpus 4.6から引き継がれた仕様ですが、ビジネス判断の観点では改めて評価する価値があります。従来、長コンテキスト処理は専用の高価格帯モデルや別料金体系で提供されることが一般的でしたが、Opus 4.7では「標準価格で1Mまで使える」という前提でアーキテクチャを設計できます。

実務では、たとえば次のようなケースで効きます。

• 大規模リポジトリ全体を一度に読み込ませる解析ワークフロー
• 数百ページに及ぶドキュメントセットの横断分析
• 長時間の会話履歴を保持し続けるエージェントシステム
• 過去のチケットやログを丸ごと参照したカスタマーサポート

これらのワークフローを「都度プロンプトを工夫して詰め込む」ではなく、「必要な情報をまとめて入れる」という設計で組めるようになります。プロンプト圧縮やRAG(Retrieval-Augmented Generation)の必要性自体は残りますが、その境界は明らかに後ろ倒しになります。

ただし、長コンテキストはトークン消費が増える方向の選択であることに変わりはありません。コスト面での恩恵は「割増がない」点であって、「無料で長くできる」という意味ではない点には注意が必要です。

↑ 目次に戻る

3. 振る舞いの変化 — 4.6から4.7で何が変わったのか

ここからは、APIパラメータ的には互換性があるものの、プロンプトの再評価や補助的な指示の見直しが必要になる挙動の変化を見ていきます。Anthropic公式のMigration Guideの「Behavior changes」セクションには9項目の変更が列挙されていますが、そのうち「高解像度画像サポート」は第2.2節で先に扱ったため、本章では残りの8項目を見ていきます。

3.1 命令を字面通りに解釈する傾向が強まった

Opus 4.7は、Opus 4.6と比べて命令をより字面通りに、明示的に解釈するようになりました。依頼されていないことを推測して実行することはなく、ある項目への指示を別の項目に黙って一般化することもありません。

この傾向は、特に低いeffortレベルで顕著に現れます。

実務的な意味は2つあります。

ひとつは、曖昧なプロンプトのリスクが上がったことです。Opus 4.6までは「察して埋めて」くれていた部分を、Opus 4.7は埋めません。「いい感じにしてください」というプロンプトは、Opus 4.7では「いい感じ」の定義をモデルが自分で決めるのではなく、最小限のスコープで返ってくる傾向があります。

もうひとつは、API用途や構造化された抽出タスクには有利だということです。丁寧にチューニングされたAPIパイプライン、構造化抽出、予測可能な挙動を必要とするワークフローでは、字面通りに解釈する傾向はむしろ歓迎されます。意図しない拡張解釈が減り、出力が予測しやすくなるためです。

一方で、対話的に「察してくれることを期待する」使い方には合わなくなりました。移行作業として、プロンプトと実行フレームワークのレビューが基本になります。

3.2 応答長がタスクの複雑さに合わせて伸縮するようになった

Opus 4.7は、応答の長さを「固定的な冗長さ」ではなく「タスクの複雑さに応じた長さ」に調整するようになりました。

具体的には、単純な問い合わせに対しては短く返し、オープンエンドな分析にはより長く返します。Opus 4.6までと同じプロンプトでも、出力の長さが変わる可能性があります。

製品の出力フォーマットや一定の冗長さに依存しているケースでは、プロンプトの調整が必要です。過剰な説明を抑えたい場合は、「簡潔で焦点を絞った応答を返してください。必須でない文脈は省き、例は最小限に抑えてください」のような明示的な指示を加えるのが基本です。

また、「やってはいけないこと」を伝える否定的な指示よりも、「こう書いてほしい」という肯定的な例示の方が効果的でもあります。

3.3 ツール呼び出しを減らし、推論を優先するようになった

Opus 4.7は、Opus 4.6と比べてツールを呼ぶ頻度が減り、その代わりに推論を多用する傾向があります。多くのケースでこれがより良い結果につながります。

ツール使用を増やしたい場合は、effortレベルを上げるのが基本です。high または xhigh のeffort設定では、エージェント的な検索やコーディングにおけるツール使用が大幅に増加します。プロンプトで明示的に「いつどのようにツールを使うべきか」を指定する方法も有効です。

3.4 Subagentをデフォルトではあまり起動しなくなった

Opus 4.7は、デフォルトでsubagentをあまり起動しなくなりました。ただしこの挙動はプロンプトで制御可能です。

並列処理や複数subagentへの明示的な委譲が必要なワークフローでは、「いつsubagentを使うべきか」をプロンプトに明示します。

3.5 トーンが直接的に、絵文字が減った

長文ライティングにおける文体が、Opus 4.6と比べて変化しています。Opus 4.7はより直接的で、より強い意見を持ち、Opus 4.6のような相手を肯定するような言い回しや絵文字が減ったスタイルです。

製品が特定のトーンや声に依存している場合(カスタマーサポート、ブランドボイス、教育コンテンツなど)、スタイル指示プロンプトをOpus 4.7のベースラインに対して再評価する必要があります。

3.6 自発的な進捗報告が増えた

長時間のエージェント処理において、Opus 4.7はより定期的で質の高い進捗報告をユーザーに返すようになりました。

ここは実務上かなり重要です。Opus 4.6までに「3回ツール呼び出しごとに進捗をまとめてください」のような進捗報告を強制する補助的な指示を組み込んでいた場合、それを外すことが公式に案内されています。

進捗報告のフォーマットや内容が用途に合わない場合は、いったん外したうえで「進捗報告はこのように出してほしい」と明示的に書き、例を提供する形に切り替えます。

3.7 Effortレベルがより厳格に守られるようになった

Opus 4.6から大きく変わった点として、Opus 4.7はeffortレベルを厳格に解釈するようになりました。特に低effort側で顕著です。

low および medium effortでは、モデルは「依頼された範囲」にスコープを絞って動作し、それを超えて気を利かせることはしません。これはレイテンシとコストの面では有利ですが、中程度に複雑なタスクを low effortで動かすと推論が浅くなるリスクがあります。

複雑な問題で浅い推論が観察された場合は、プロンプトで回避するのではなくeffortを high または xhigh に上げるのが基本です。

レイテンシ要件で low を維持する必要がある場合は、ターゲットを絞った指示を追加します。「このタスクは多段階の推論を含みます。応答する前に問題をよく考えてください」といった具体的な指示が有効です。

3.8 セキュリティ関連トピックの拒否が強化された

Opus 4.7で新たに追加された挙動として、禁止されたトピックや高リスクなトピックに関するリクエストは拒否される可能性が高まりました。リアルタイムのサイバーセキュリティ関連の安全策が組み込まれています。

ペネトレーションテスト、脆弱性研究、レッドチーミングといった正当なセキュリティ業務でこのモデルを使う場合、AnthropicのCyber Verification Programに申請することで制限の緩和を受けられます。

3.9 これらの変化が業務ワークフローに与えるインパクト

ここまでの8項目を業務インパクトの観点でまとめると、ポイントは4つです。

まず、プロンプト設計の力点が「察してもらう」から「明示する」に移ったこと。Opus 4.7は字面通りに読み、依頼されたスコープに絞って動きます。曖昧さを残したプロンプトは、4.6時代より結果のばらつきが大きくなります。

次に、4.6時代に組み込んだ補助的な指示は、外して再評価するのが基本ラインだということ。進捗報告の強制、過剰な確認指示、subagentへの明示的な誘導といった足場は、4.7では逆効果になり得ます。

そして、effortレベルをタスクに応じて意識的に選ぶ運用が前提になったこと。これまでデフォルト任せでよかった部分が、4.7では明示的な選択を求めます。

最後に、スタイルやトーンに依存する製品は、必ず再ベースライン化が必要だということ。Opus 4.6とOpus 4.7では、同じプロンプトでも文体・長さ・絵文字使用が変わります。

これらは破壊的変更ではないため、プロンプトを変えなくても動作はします。ただし、品質を維持・向上させたいのであれば、移行時のレビューは避けて通れません。

↑ 目次に戻る

4. 補足:Claude Code利用者も知っておきたいMessages API側の破壊的変更

本記事はClaude Codeでの利用を主軸にしています。ただし、Opus 4.7ではMessages API側にも破壊的変更があり、モデル挙動の理解や移行判断に関係します。そのため、Claude Code利用者にも影響し得る範囲でAPI側の変更点も補足します。

なお、ここで扱う変更はMessages APIを直接利用しているケースのみに該当します。Claude Managed Agentsを利用している場合は、Messages API直接利用とは移行手順が異なります。詳細は公式Migration Guideを確認してください。

4.1 Extended thinking budgetsの廃止とadaptive thinkingへの一本化

Opus 4.7では、固定のthinking budgetモードが廃止されました。

# Opus 4.6(動作する)
thinking = {"type": "enabled", "budget_tokens": 32000}

# Opus 4.7(400エラー)
thinking = {"type": "enabled", "budget_tokens": 32000}

Opus 4.7でthinkingを有効化する唯一の方法はadaptive thinkingです。代わりに、思考の深さは effort パラメータで制御します。

# Opus 4.7での書き方
response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=64000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},
    messages=[{"role": "user", "content": "..."}],
)

Anthropicの内部評価では、adaptive thinkingは固定budgetのextended thinkingを一貫して上回る性能を示しているとされています。

4.2 Adaptive thinkingのデフォルト無効と明示的な有効化

Messages APIにおける重要な仕様として、Opus 4.7ではadaptive thinkingがデフォルトで無効です。

thinking フィールドを指定しないリクエストは、thinkingなしで実行されます。これはOpus 4.6の挙動と一致しています。Thinkingを有効にしたい場合は thinking: {type: "adaptive"} を明示的に指定します。

なお、これはMessages API直接利用時の話です。後述するClaude Codeでは、effort levelを通じた制御に統一されており、ユーザーがthinkingを意識的に切り替える必要はありません。

4.3 Samplingパラメータの禁止

Opus 4.7では、temperature、top_p、top_k のいずれかをデフォルト値以外に設定すると400エラーになります。

最も安全な移行方針は、これらのパラメータをリクエストペイロードから完全に削除することです。Opus 4.7でモデルの挙動を制御する手段は、プロンプトでの誘導が基本です。

temperature = 0 を決定論的な出力のために使っていたケースについて、これは過去のモデルでも同一出力を保証するものではなかった、と公式ドキュメントには注記があります。完全な再現性が必要な用途では、別のアーキテクチャ(出力のキャッシュ、構造化出力の活用など)を検討する必要があります。

4.4 Thinking contentのデフォルト省略とdisplayオプション

Opus 4.7では、レスポンス内のthinkingブロックがデフォルトで空になりました。Thinkingブロック自体はレスポンスストリームに含まれますが、display: "summarized" を明示的に指定しない限り、thinking フィールドは空のまま返ります。

これはサイレントな変更です。エラーは発生しませんが、Opus 4.6では要約されたthinkingテキストが返っていたのに、Opus 4.7では何も返らなくなります。

UI上で思考プロセスを表示している製品の場合、復元するには次の設定を加えます。

thinking = {
    "type": "adaptive",
    "display": "summarized",  # デフォルトは "omitted"
}

特に思考プロセスをユーザーにストリーム表示している製品では、この設定を入れないと「出力前に長い無音時間が発生する」ように見えるため、注意が必要です。

4.5 新トークナイザーによる max_tokens 設定の見直し

新トークナイザーの導入により、同じテキストでも消費トークン数が変わります。具体的な影響範囲は次の通りです。

• /v1/messages/count_tokens の返り値がOpus 4.6と異なる
• クライアント側でトークン数を見積もるコードパスは再テストが必要
• 文字数とトークン数の固定比率を仮定するロジックは要検証
• max_tokens には余裕を持たせる必要がある
• コンテキスト圧縮のトリガー条件は再調整が必要

max または xhigh effortで動かす場合、max_tokens を64,000トークン以上から開始してチューニングするのが基本になります。Subagentやツール呼び出しを跨いだ思考と行動のために、十分な出力予算が必要です。

4.6 Prefillの廃止(Opus 4.6から継続)

これはOpus 4.6で既に導入された変更ですが、4.5以前から直接移行する場合は注意が必要です。Opus 4.7では、アシスタントメッセージのprefillが400エラーになります。

代替手段は次の通りです。

• 構造化出力(structured outputs)の利用
• システムプロンプトでの指示
• output_config.format の利用

Prefillの典型的な用途と、それぞれの推奨移行先を整理します。

↑ 目次に戻る

5. 新機能

5.1 xhigh effort levelの追加と推奨デフォルト化

Opus 4.7では、effortパラメータに xhigh という新しいレベル が追加されました。これは high と max の中間に位置します。Claude Codeのコーディング・エージェント用途では、xhigh を基本線にする運用がリリース時から繰り返し示されています。一方、Messages APIを直接利用する場合は、APIのデフォルト値と用途別の推奨値を分けて確認するのが安全です。

各レベルの位置づけは次の通りです。

Opus 4.7では、effortがこれまでのOpusよりも重要になる、というのが公式リリースで強調されているメッセージです。アップグレード時には積極的に試してみるのが基本です。

つまりOpus 4.7では、「とりあえずデフォルト」ではなく、用途に応じてeffortを意識的に選ぶ運用が前提になっています。

max の使用については慎重さが求められます。maxには「収穫逓減(diminishing returns)」と「必要以上に考え込む傾向」が明記されており、難しいタスクで実テストしてから広く採用するのが安全です。

5.2 Task budgets(beta)

Opus 4.7で導入された新機能として、task budgetsがあります。これは、エージェントループ全体(思考、ツール呼び出し、ツール結果、最終出力すべてを含む)に対する助言的なトークン予算をモデルに伝える仕組みです。

モデルはこの予算と、進行中のカウントダウンを認識し、それに基づいて作業を優先順位付けし、予算が消費されるにつれてタスクを適切に終了させます。

利用方法は次の通りです。

response = client.beta.messages.create(
    model="claude-opus-4-7",
    max_tokens=128000,
    output_config={
        "effort": "high",
        "task_budget": {"type": "tokens", "total": 128000},
    },
    betas=["task-budgets-2026-03-13"],
    messages=[
        {"role": "user", "content": "Review the codebase and propose a refactor plan."}
    ],
)

max_tokens との違いを明確にしておきます。

max_tokens は「絶対に超えない上限」、task_budget は「目標として伝える予算」と理解すると正確です。

使い分けの目安は以下の通りです。

• 品質重視のオープンエンドなエージェントタスクにはtask budgetを設定しない
• ワークロードを特定のトークン量に収める必要がある場合に利用する
• 最小値は20,000トークン
• 予算が制限的すぎると、タスクが浅くなったり、モデルが予算を制約として明示的に言及したりする

実用上は、CI/CDパイプラインに組み込むエージェントや、コスト上限を厳格に管理する必要があるバッチ処理に向いています。対話的な探索や創造的な作業には不向きです。

5.3 ファイルベースメモリの改善

Opus 4.7は、ファイルシステムベースのメモリの読み書き能力が改善されています。スクラッチパッド、ノートファイル、構造化メモリストアをターン跨ぎで利用するエージェントは、自分用のメモを書き残し、それを後のタスクで活用する能力が向上しています。

自前で構築せずに利用したい場合は、Anthropicが提供するclient-sideのmemory toolを使うことで、管理されたスクラッチパッドをClaudeに与えられます。

長期にわたるエージェントワーク、複数セッションをまたぐプロジェクト、複雑なコンテキストを蓄積していくワークフローで、この改善は意味を持ちます。

ここまで見てきたように、Opus 4.7は単に性能が上がったモデルではありません。命令解釈、応答長、ツール使用、進捗報告、subagentの扱い、effort制御まで、エージェントとしての振る舞いが変わっています。

この変化が最も実務に現れやすいのが Claude Code です。以降では、CLI版とWeb版のClaude Codeで、Opus 4.7をどのように使いこなすべきかを見ていきます。

↑ 目次に戻る

第2部:Claude Code CLI版で使うOpus 4.7

6. Claude CodeにおけるOpus 4.7の前提

Claude Codeは、ターミナルで動作するAnthropic公式のエージェント型コーディングツールです。Opus 4.7を業務で活用する場合、CLIを経由した利用が最も柔軟性が高く、本記事ではその前提で解説していきます。本章のモデル設定関連の仕様は、公式のModel configurationドキュメントに基づきます。

6.1 バージョン要件と更新手順

Opus 4.7をClaude Codeで利用するには、Claude Code v2.1.111以降が必要です。これより古いバージョンではOpus 4.7を呼び出せません。

現在のバージョン確認と更新は次のコマンドで行います。

# 現在のバージョン確認
claude --version

# 最新版に更新
claude update

特定バージョンを指定してインストールする場合は次の通りです。

claude install 2.1.118
claude install stable
claude install latest

6.2 モデルエイリアスの解決ルール

Claude Codeでは、opus や sonnet といったエイリアスを使ってモデルを指定できます。ただし、エイリアスがどのモデルに解決されるかは利用環境によって異なります。

これはClaude Codeにおけるaliasの解決先の話であり、Bedrock / Vertex AI / FoundryでOpus 4.7自体が利用できないという意味ではありません。Opus 4.7はこれらのサードパーティプラットフォームでも提供されています。最新モデルを使う場合は、フルモデル名(claude-opus-4-7 など)を明示的に指定するか、ANTHROPIC_DEFAULT_OPUS_MODEL 環境変数を設定する必要があります。

エイリアスは時間とともに更新されるため、特定バージョンに固定したい場合はフルモデル名を使うのが安全です。

6.3 プラン別のデフォルトモデル

Claude Code起動時のデフォルトモデルは、契約プランによって異なります。これは特に意思決定者にとって重要な情報です。

つまり、ProプランやTeam Standardプランの利用者は、明示的に切り替えない限りOpus 4.7を使っていません。コーディングや複雑なエージェントタスクでOpus 4.7を使いたい場合、/model opus で切り替える必要があります。

なお、2026年4月23日からはEnterprise pay-as-you-goとAnthropic APIユーザーのデフォルトもOpus 4.7に変更されます。

↑ 目次に戻る

7. Claude Codeの基本操作 — CLIコマンドの使い方一覧

ここでは公式ドキュメントに記載されている主要なコマンドを、利用頻度の高いものから整理します。網羅的な一覧は公式のCLI referenceを参照してください。

7.1 起動と終了

最も基本的な起動・終了の操作です。

セッション中の終了は Ctrl+C を二回、もしくは /exit コマンドで行います。

claude -c と claude -r の違いは押さえておくと便利です。-c は「現在のディレクトリでの最新会話」を引き継ぐもので、-r は「特定のセッション名やIDを指定して再開」するものです。複数のプロジェクトを並行で進めている場合、セッションに名前を付けておくと再開時に明確に区別できます。

7.2 セッション中のスラッシュコマンド早見表

セッション中にプロンプト入力欄で / を入力すると、利用可能なコマンドの一覧が表示されます。実務でよく使うものは次の通りです。

特に意識して使いたいのは次の3つです。

/effort はOpus 4.7で重要なコマンドです。タスクの性質に応じて切り替える運用が基本になります。

/effort xhigh    # コーディングやagenticタスクの推奨
/effort high     # コスト・並列実行重視
/effort medium   # コスト重視のスコープが小さいタスク
/effort max      # 最高難度タスクで意図的に使う

/compact は長時間セッションでコンテキストが膨らんできたときに使います。Claude Codeは限界が近づくと自動的にトリガーしますが、長いタスクの前に明示的に圧縮しておくのも有効です。

/model はモデルを切り替えます。ProプランでSonnet 4.6がデフォルトの場合、複雑なタスクの前に /model opus でOpus 4.7に切り替える運用が必要です。

7.3 設定ファイルの階層

Claude Codeの設定には、モデル選択の優先順位とsettingsファイル全体のスコープ優先順位という、2つの異なる階層があります。混同しやすいため、それぞれ分けて見ていきます。

モデル選択の優先順位(高い順)

/model、--model、ANTHROPIC_MODEL、settings.json の model フィールドの間では、次の順序で優先されます。

1. セッション中の /model コマンド
2. 起動時の --model フラグ
3. 環境変数 ANTHROPIC_MODEL
4. settingsファイルの model フィールド

settingsファイル全体のスコープ優先順位(高い順)

permissions、hooks、env、availableModels といったsettings全体の優先順位は、Anthropic公式のClaude Code settingsドキュメントで次のように定められています。

1. Managed settings(最高、上書き不可)
2. Command line arguments(一時的なセッションオーバーライド)
3. .claude/settings.local.json(プロジェクトローカル、Git管理対象外)
4. .claude/settings.json(プロジェクト共有、Git管理対象)
5. ~/.claude/settings.json(ユーザー設定、最も低い)

Managed settingsはIT部門やDevOpsチームが配布する組織ポリシー用で、サーバー管理、MDM/OSレベルのポリシー、ファイルベースのいずれかの形で配布されます。これは最高優先度で、ユーザーやプロジェクトの設定からは上書きできません。

なお、配列形式の設定値(permissions.allow や sandbox.filesystem.allowWrite など)は、複数のスコープにまたがって結合・重複排除されます。上書きではなく追記される、というのが重要なポイントです。

実務では、次のような使い分けが想定されます。

• ユーザー設定(~/.claude/settings.json):個人の好みのデフォルトeffortや好みのモデル
• プロジェクト設定(.claude/settings.json):プロジェクト固有のツール権限、利用可能モデル制限
• ローカル設定(.claude/settings.local.json):個人がプロジェクト内で一時的に上書きしたい設定

設定ファイルの基本的な構造は次の通りです。

{
  "model": "opus",
  "effortLevel": "xhigh",
  "permissions": {
    "allowedTools": ["Read", "Write", "Bash(git *)"],
    "deny": ["Read(./.env)", "Read(./.env.*)"]
  }
}

7.4 環境変数で覚えておくべきもの

公式ドキュメントから、業務でよく使う環境変数を整理します。

サードパーティ環境(Bedrock、Vertex、Foundry)でのモデルピン留めには、それぞれ専用の ANTHROPIC_DEFAULT_OPUS_MODEL 等を使います。

# Bedrockの例
export ANTHROPIC_DEFAULT_OPUS_MODEL='us.anthropic.claude-opus-4-7'

# 1Mコンテキストを有効にしたピン留め
export ANTHROPIC_DEFAULT_OPUS_MODEL='claude-opus-4-7[1m]'

7.5 状態確認の作法

「今どのモデル・どのeffortで動いているか」を確認する手段は複数あります。

最も簡単なのはステータス行です。Claude Codeはロゴとスピナーの隣に現在のeffortレベル(例:with xhigh effort)を常時表示します。これで現在の設定を一目で確認できます。

詳細を確認したい場合は /status を使います。これでモデル名、プラン情報、認証状態がJSONで返ります。

セッション終了時に「結局このタスクでいくらかかったか」を知りたい場合は /usage を使います。入出力トークン数とコスト概算が表示されます。

↑ 目次に戻る

8. 日常運用のリズム — Claude Codeをふだんどう使うか

ここからは、公式ブログ「Best practices for using Claude Opus 4.7 with Claude Code」(2026年4月16日)で示されている運用指針を中心に、ふだんの使い方を見ていきます。

Opus 4.7の使い方の基本姿勢は、「ペアプログラマーとしてではなく、業務を委譲する有能なエンジニアとして扱う」というものです。一行ずつ指導するのではなく、必要な情報を渡して任せる、という発想の転換です。

この姿勢の転換が、以下のすべての運用作法の根拠になります。

8.1 タスク投入の基本フロー — 初回ターンに全部入れる

Opus 4.7で最も重要なのは、初回ターンにタスクを完全に記述することです。初回プロンプトには、少なくとも次の4点をまとめて渡すのが基本です。

• 意図(何を達成したいか)
• 制約(守るべきルール、使ってはいけない技術、既存設計への配慮)
• 完了条件(どうなれば完了と判定するか)
• 関連ファイルの場所(どのファイルを参照・編集すべきか)

複数ターンに分けて曖昧なプロンプトを出すアプローチは、トークン効率も最終品質も下がる傾向があります。

初回プロンプトのテンプレート例を示します。

[Intent]
ユーザー認証APIをOAuth 2.0ベースに移行する。

[Constraints]
- 既存のセッション管理ロジック(src/auth/session.ts)は変更しない
- 移行は段階的に行い、既存の認証エンドポイントとの互換性を保つ
- TypeScriptのstrictモードを維持

[Acceptance criteria]
- 既存テスト(tests/auth/)がすべてパスすること
- 新しいOAuthフロー用のE2Eテストが追加されていること
- README.mdの認証セクションが更新されていること

[Relevant files]
- src/auth/*.ts
- tests/auth/*.test.ts
- README.md

このように初回で全情報を渡すと、Opus 4.7は途中で確認を挟まずに最後まで進めようとします。これが「任せる」運用の基本形です。

8.2 ユーザーターン数を減らす

2つ目の指針は、ユーザーとのインタラクション回数を減らすことです。

これはOpus 4.7の特性に基づく指針です。Opus 4.7はインタラクティブな設定でユーザーターンの後により多く推論する傾向があり、その推論がコヒーレンス・指示追従・コーディング品質を向上させます。一方で、ターンが増えるたびにトークン消費も増加します。

実務では、次のような運用が基本になります。

• 「これで合っていますか?」のような確認質問を最小限に絞る
• 修正指示があれば一度にまとめて伝える
• 「次のステップに進んでください」のような中継的なターンを減らす

8.3 Auto Modeの活用

Opus 4.7の長時間自律実行性能を最大限引き出す機能として、Auto Modeがあります。

Auto Modeは、モデルが安全に実行できると判断したタスクについて、頻繁な確認なしで実行できるモードです。長時間タスクで初回プロンプトに完全なコンテキストを与えた場合に特に有効です。

利用方法は次のいずれかです。

# 起動時からAuto Modeで開始
claude --permission-mode auto

セッション中であれば、Shift+Tab を押すことで権限モードが切り替わります(normal → auto-accept on → plan modeの順にサイクル)。

Auto ModeはClaude Code Maxユーザー向けの試験提供版(research preview)機能として提供されています。

8.4 完了通知の設定

長時間タスクをAuto Modeで走らせる際の運用上の工夫として、タスク完了通知の設定が便利です。Claude自身に「タスク完了時に音を鳴らすフックを設定してほしい」と頼めば、Claude Codeのhook機能を使ってその設定を組んでくれます。

8.5 effortレベルをタスクに応じて切り替える

effortレベルは「最初に設定して放置する」のではなく、タスクの性質に応じて切り替えていく運用が基本です。同じタスク内であっても、トークン使用と推論をより効果的に管理するためにeffortを切り替えてよい、というスタンスです。

具体的な切り替え例を整理します。

8.6 thinkingの量をプロンプトで制御する

Opus 4.7ではアダプティブシンキングモードが常時動作し、固定budgetは廃止されました。thinkingの量を制御したい場合は、プロンプトで直接指示します。

具体例は次の通りです。

もっと考えてほしい場合
「ステップバイステップに、慎重に考えてから応答してください。この問題は見た目より難しいです。」

もっと早く返してほしい場合
「深く考えるよりも、素早い応答を優先してください。迷ったら直接答えてください。」

後者を使うとトークンを節約できますが、難しいステップで精度が下がる可能性がある点に留意が必要です。

8.7 Subagentの扱い

Opus 4.7はデフォルトでsubagentをあまり起動しません。並列実行が必要なタスクでは、明示的に指示を出す必要があります。

具体例として示されているプロンプトは、要約すると次のような内容です。

単一の応答で完結できる作業(既に見えている関数のリファクタなど)にはsubagentを作らないこと。複数のアイテムにまたがる作業や複数ファイルを読む場合は、同じターン内で複数のsubagentを作ること。

つまり、subagentを使うべき条件は2つに絞られています。

• 複数アイテムへの並列処理
• 複数ファイルの並列読み取り

これ以外のケースでは、Claude自身の判断に委ねるのが基本です。

8.8 4.6時代の補助的な指示を外す

ここまで触れてきた指針と関連して重要なのが、Opus 4.6までに組み込んだ補助的な指示を外すことです。

Migration Guideで明示的に外せと言われているのは次の3パターンです。

進捗報告を強制するプロンプト。「3回ツール呼び出しごとに進捗をまとめてください」のような指示は、Opus 4.7では自発的に行うようになったため不要です。

確認を強制するプロンプト。「スライドのレイアウトを返す前にダブルチェックしてください」のような指示は、Opus 4.7が自己検証するようになったため、外して再評価するのが基本です。

出力長を一定に保つためのプロンプト。Opus 4.7はタスクの複雑さに応じて長さを調整するため、固定的な冗長さを期待した指示は外して、必要なら明示的にスタイルを指示します。

これらの補助的な指示を外すと、トークン消費が減り、応答品質が安定する場合があります。

8.9 1日の典型的なワークフロー

ここまでの指針をまとめると、Opus 4.7でClaude Codeを使う1日のリズムはこんなかんじになります。

朝:セッション開始

# 新しいタスクを始める場合
claude -n "feature-oauth-migration" --model opus --effort xhigh

# 昨日の続きを再開する場合
claude -r "feature-oauth-migration"

タスク投入:初回プロンプトで全情報を渡す

意図 / 制約 / 完了条件 / 関連ファイルの4要素を含むプロンプトを書きます。長くなっても構わないので、後から「これも追加で」と細切れに渡すよりも初回に詰め込みます。

実行中:基本的に介入しない

Auto Modeを使っている場合は完了通知を待ちます。介入が必要になっても、まとめて一度に伝えます。中継的な「次に進んで」のターンは避けます。

完了後:レビューと検証

/review で変更点を確認、必要に応じてテストを走らせます。完了条件に対する達成度をClaude自身に確認させます。

コンテキストの管理

長時間セッションで応答が遅くなってきたら /compact で履歴を圧縮します。タスク自体が変わるなら /clear で新しいセッションに切り替えるか、claude -n で別セッションを立ち上げます。

終了時:セッション保存

/exit で終了します。セッション名を付けておけば翌日 claude -r <name> で再開可能です。

↑ 目次に戻る

9. Effort Levelの使い分け

第8章で運用の中での切り替え方を扱いましたが、ここでは公式ドキュメントに基づく各レベルの正確な定義を整理します。

9.1 5段階の公式定義

Opus 4.7では、effortレベルが5段階に拡張されました。Opus 4.6とSonnet 4.6は4段階のままです。

9.2 xhighをデフォルトとして使う理由

xhighは大半のコーディングおよびエージェント用途で最良の設定として位置づけられています。max が長時間実行で起こしうる暴走的なトークン消費なしに、強い自律性と知性を発揮するためです。

つまりxhighは、max の知性を90%カバーしつつ、max の必要以上の考え込みリスクを回避する設定です。

xhighが基本になる用途は次の通りです。

• API・スキーマ設計
• レガシーコードの移行
• 大規模コードベースのレビュー
• 一般的なagenticコーディング

9.3 maxが考え込みすぎる場面と回避策

max は性能向上の可能性がある一方、収穫逓減と必要以上に考え込む傾向が公式ドキュメントに明記されています。これはOpus 4.7のリリース時から繰り返し強調されているポイントです。

max の適切な用途は次のように限定されます。

• 評価でモデルの最大性能を測定する場合
• 知性が極めて重要で、コストを問わない用途
• 真に困難な問題でxhighが解けなかった場合の試行

逆に、日常的なコーディングや通常のエージェント実行で max を常用すると、トークン消費が増えるだけで品質向上は限定的、という結果になりがちです。

9.4 設定方法

effortレベルの設定方法を優先順位順に整理します。

(1) セッション中の /effort コマンド(最も即時性が高い)

/effort                # スライダーを開く
/effort xhigh         # 直接指定
/effort auto          # モデルのデフォルトに戻す

(2) /model ピッカー内のスライダー

/model でピッカーを開いた状態で左右矢印キーを押すとeffortスライダーが操作できます。

(3) 起動時のフラグ

claude --effort xhigh

(4) 環境変数

export CLAUDE_CODE_EFFORT_LEVEL=xhigh

(5) 設定ファイル

{
  "effortLevel": "xhigh"
}

(6) Skill / Subagentのフロントマター

特定のSkillやSubagentが動作する間だけ別のeffortを使いたい場合、それぞれのMarkdownファイルのフロントマターに effort を指定できます。

優先順位は、環境変数が最も強く、次に設定値、最後にモデルデフォルトです。フロントマター指定はそのSkill / Subagentが動作している間のセッション設定を一時的に上書きしますが、環境変数は上書きできません。

なお、low / medium / high / xhigh はセッションを跨いで永続化されますが、max だけは現セッション限りです(環境変数経由で設定した場合は永続化)。

9.5 ultrathink — 1ターンだけ深く考えさせる小ワザ

セッション全体のeffort設定を変更せずに、特定の1ターンだけ深く考えさせたい場合の小ワザがあります。

プロンプトに　"ultrathink" という単語を含めると、そのターンだけ文脈内の追加指示として「より深く推論せよ」という命令が加わります　。これはeffortレベルそのものを変更するものではなく、APIに送られるeffort値も変わりません。

実装上は単純な仕組みですが、「全体はxhighで動かしたいが、この一手だけは念入りに考えてほしい」という場面で使えます。

↑ 目次に戻る

10. 1Mコンテキストの正確な扱い方

10.1 プラン別の可用性マトリクス

Opus 4.7、Opus 4.6、Sonnet 4.6は1Mトークンのコンテキストウィンドウをサポートしています。利用可否はプランによって異なります。

Max、Team、Enterpriseプランでは、opus を選択すると追加設定なしで1Mコンテキストに自動アップグレードされます。

10.2 1Mに追加プレミアムが付かない料金体系の意味

公式ドキュメントには、1Mコンテキストウィンドウは標準モデル価格を使用し、200Kトークンを超える分にプレミアムは付かないと明記されています。

これはOpus 4.6から引き継がれた仕様ですが、ビジネス判断として改めて認識しておく価値があります。

長コンテキスト処理に対する割増料金がないため、次のようなアーキテクチャ判断が変わります。

• 大規模リポジトリ全体を読み込むワークフローの設計
• 大量のドキュメントセットの横断分析
• 過去のチケット・ログを丸ごと参照するエージェントシステム

ただし、トークン消費自体は当然増えるため、コスト管理には引き続き task_budget や effort の調整が必要です。

10.3 opus[1m] エイリアスと [1m] サフィックスの使い方

Max / Team / Enterpriseプランでは自動アップグレードされるため明示は不要ですが、明示的に1Mを指定したい場合や、Proプランでextra usage経由で1Mを使う場合は次のように指定します。

# セッション中の切り替え
/model opus[1m]
/model sonnet[1m]
/model claude-opus-4-7[1m]

サードパーティ環境でモデルをピン留めする場合は、環境変数に [1m] サフィックスを付けます。

export ANTHROPIC_DEFAULT_OPUS_MODEL='claude-opus-4-7[1m]'

このサフィックスは opusplan を含むそのエイリアスのすべての利用に1Mを適用します。Claude Codeはプロバイダーに送る前にサフィックスを除去します。[1m] を使えるのは、Opus 4.7やSonnet 4.6のように1Mコンテキストをサポートするモデルだけです。

10.4 注意点:opusplanは1Mに自動アップグレードされない

落とし穴として明確に押さえておきたい仕様があります。

opusplan モデルエイリアスは、PlanモードでOpus、実行モードでSonnetを使うハイブリッドモードです。便利な機能ですが、opusplan のPlanモード時のOpusフェーズは標準の200Kコンテキストで動作します。10.1で説明した1M自動アップグレードは opus モデル設定にのみ適用され、opusplan には及びません。

つまり、Maxプランで「自動的に1Mが使える」と思って opusplan を使うと、PlanフェーズのOpusは200K止まりになります。大規模リポジトリのプランニングで1Mを使いたい場合は、opusplan ではなく opus を直接使う必要があります。

opusplan で1Mを使いたい場合は、環境変数で [1m] サフィックスを明示的に付ける方法があります。

export ANTHROPIC_DEFAULT_OPUS_MODEL='claude-opus-4-7[1m]'

10.5 1Mを無効化するケース

何らかの理由で1Mコンテキストを利用したくない場合は、環境変数で無効化できます。

export CLAUDE_CODE_DISABLE_1M_CONTEXT=1

これを設定すると /model ピッカーから1Mバリアントが除外されます。

無効化を検討する典型的なケースは、コスト上限を厳格に管理したい場合や、コンテキスト圧縮の挙動を従来通りに保ちたい場合などです。

↑ 目次に戻る

11. Claude CodeにおけるAdaptive Reasoning

第4.1〜4.2節で扱ったadaptive thinkingはMessages APIの話でしたが、Claude Codeでは同じ概念が「adaptive reasoning」として、effort levelを通じて制御される仕組みになっています。本章ではClaude Code側の挙動を見ていきます。

11.1 Opus 4.7ではadaptive reasoningが常時動作し、無効化できない

Claude Code公式ドキュメントに明記されている重要な仕様です。Opus 4.7ではadaptive reasoningが常時動作し、これを無効化する手段は存在しません。固定thinking budgetモード(CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING など)はOpus 4.7では効きません。

これは、Opus 4.7ではユーザーが「thinkingの量」を直接的に指定する手段がない、ということを意味します。代わりに次の二つの間接的な手段があります。

• effortレベルによる制御(レベルが高いほどthinkingが増える傾向)
• プロンプトでの誘導(第8.6節で説明した方法)

つまり、Messages APIでは thinking パラメータで明示的に有効化／無効化を切り替えるのに対し、Claude Codeではeffort levelがその役割を担う、というアーキテクチャの違いがあります。

11.2 4.6で残っている固定thinking budget

参考までに、Opus 4.6とSonnet 4.6では従来の固定thinking budgetモードが残っています。

# Opus 4.6 / Sonnet 4.6で固定budgetに戻す
export CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1
export MAX_THINKING_TOKENS=32000

ただしこれらのモデルでも公式ドキュメントはadaptive thinkingを推奨しており、固定budgetモードは互換性のために残っている位置づけです。Opus 4.7への移行を見据えるなら、4.6の段階からadaptive thinkingベースの運用に切り替えておくのが合理的です。

11.3 プロンプトとCLAUDE.mdによる誘導の作法

thinkingの量をコントロールする最も確実な方法は、プロンプトでの直接指示です。これは個別のターンに書く方法と、CLAUDE.mdなどで常時適用する方法の二段構えで運用できます。

ターン単位での指示は第8.6節の例文を参照してください。

CLAUDE.mdレベルで「このプロジェクトでは慎重に考えてほしい」という指示を入れる場合は、自然言語で書きます。

# Project Guidelines

## Reasoning style
This project handles financial transactions. Think carefully and verify
your reasoning step-by-step before making changes to payment-related code.

このような指示は、effort設定の上に重なる形で動作します。

↑ 目次に戻る

12. Opus 4.7を最大限引き出すプロンプティング

ここまでの章で運用と設定の話をしてきました。最後に、Opus 4.7におけるプロンプト設計の原則を整理します。すべて公式ブログと公式Prompting Best Practicesに基づきます。

12.1 「依頼書」スタイル

第8.1節で示した4要素を、改めて構造として整理します。

• 意図(何を達成したいか)
• 背景(既存設計、使用技術)
• 制約(守るべきルール、禁止事項)
• 完了条件(完了の判定基準)

これは「指示」ではなく「依頼書」です。ペアプログラマーへの会話ではなく、外部のシニアエンジニアに渡す業務委託の指示書を書くという発想で組み立てます。

12.2 否定形より肯定形の例示

Migration Guideが明確に示している原則として、適切なコミュニケーションの仕方を示す肯定的な例示の方が、否定的な指示よりも効果的だ、というものがあります。

たとえば「冗長にしないでください」と書くより、「次のような簡潔さで応答してください:[例文]」と書く方が効きます。

12.3 effortとthinkingはプロンプトと組み合わせて使う

effortレベルだけでも、プロンプトだけでも完全には制御できません。両者の組み合わせが基本です。

12.4 Subagentや並列化を明示する

Opus 4.7はデフォルトで控えめにsubagentを起動するため、並列化が必要なら明示的に指示します。第8.7節のプロンプト例を参考にしてください。

12.5 検証機構を渡す

公式Prompting Best Practicesには、コードレビューハーネスのチューニングについて重要な記述があります。Opus 4.7はバグ発見性能が大幅に向上しており、Anthropic内部の評価ではrecall(バグ検出再現率)が11pp改善しています。一方で、Opus 4.6向けに調整されたハーネスでは初期にrecallが下がって見えることがある、という注意喚起もあります。

これはOpus 4.7が指示により忠実だからです。「重大な問題のみ報告してください」「保守的に」「些細なことは指摘しないで」といった指示を、Opus 4.6よりも忠実に守ります。同じ深さで調査しても、報告される件数が減る、ということが起こります。

実務的な意味は、Opus 4.7に切り替えた直後は、ハーネスのプロンプトを再評価する必要があるということです。指示を緩めるか、報告基準を明示し直すことで、本来の性能を引き出せます。

↑ 目次に戻る

13. エンタープライズ運用

ここからは、チームや組織でClaude Codeを使うときのガバナンスとコスト管理について見ていきます

13.1 availableModelsによるモデル制限

エンタープライズ管理者は、availableModels 設定でユーザーが選択可能なモデルを制限できます。

{
  "availableModels": ["sonnet", "haiku"]
}

これをmanaged settingsまたはpolicy settingsに置くと、ユーザーは /model、--model フラグ、ANTHROPIC_MODEL 環境変数のいずれを使ってもリストにないモデルに切り替えられなくなります。

ただし注意点として、Defaultオプション(モデルピッカーの「Default」選択肢)は availableModels の影響を受けません。Defaultは常に表示され、ユーザーのプラン階層に応じたシステムデフォルトに解決されます。

availableModels を [] に設定しても、ユーザーはDefaultモデルでClaude Codeを利用できます。

13.2 defaultモデル設定とプラン別フォールバック

ユーザーが「Default」を選択した場合のモデルを完全に制御するには、3つの設定を組み合わせる必要があります。

{
  "model": "claude-sonnet-4-5",
  "availableModels": ["claude-sonnet-4-5", "haiku"],
  "env": {
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-sonnet-4-5"
  }
}

この例では、ユーザーをSonnet 4.5で起動し、ピッカーをSonnetとHaikuに制限し、Default選択時の解決先もSonnet 4.5に固定しています。

env ブロックがないと、Defaultを選んだユーザーは最新のSonnetリリースに自動的にアップグレードされ、model と availableModels で固定したバージョンがバイパスされます。

13.3 サードパーティでのモデルピン留め

Bedrock、Vertex AI、Foundryでデプロイする場合、本番ロールアウト前にモデルバージョンをピン留めしておくのが基本です。

# Bedrockの例
export ANTHROPIC_DEFAULT_OPUS_MODEL='us.anthropic.claude-opus-4-7'

# Vertex AIの例
export ANTHROPIC_DEFAULT_OPUS_MODEL='claude-opus-4-7'

# Foundryの例
export ANTHROPIC_DEFAULT_OPUS_MODEL='claude-opus-4-7'

ピン留めしないと、Claude Codeはエイリアスを最新版に解決します。Anthropicが新しいモデルをリリースした際、ユーザーのアカウントでまだ有効化されていない場合、BedrockやVertex AIのユーザーは前バージョンへフォールバックする通知を見ることになり、Foundryユーザーはエラーを見ることになります。

ピン留めしておけば、新モデルへの移行タイミングを組織側で管理できます。

13.4 Prompt cachingの制御

Claude Codeは自動的にprompt cachingを利用してパフォーマンスとコストを最適化します。これを無効化したい場合は次の環境変数を使います。

特定モデルのデバッグや、クラウドプロバイダーごとに異なるキャッシュ実装の検証で使います。

13.5 ガバナンスとコスト管理の観点でチームに敷くべき設定

組織展開する際の設定指針をまとめます。

(1) モデルの制限

セキュリティや予算上の理由で特定モデルだけを許可したい場合は、managed settingsに availableModels を設定します。これは最高優先度で、ユーザー側からは上書きできません。

(2) effortレベルのデフォルト

組織として「コスト重視で運用したい」「品質重視で運用したい」の方針がある場合、ユーザー設定で effortLevel のデフォルトを揃えます。Proプランでも品質を確保したい場合は effortLevel: high 以上が目安、コスト重視なら medium を出発点として検討します。

(3) 1Mコンテキストの制御

大規模リポジトリで1Mを活用したいケースがある一方、コスト爆発を避けたいケースもあります。組織として1Mを制限したい場合は CLAUDE_CODE_DISABLE_1M_CONTEXT=1 をmanaged settings経由で配布します。

(4) ツール権限のガードレール

.claude/settings.json でツール権限を細かく定義し、リポジトリにコミットします。これによりチーム全員に同じ権限ルールが適用されます。

{
  "permissions": {
    "allowedTools": ["Read", "Write", "Bash(git *)", "Bash(npm *)"],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Write(./production.config.*)"
    ]
  }
}

(5) 利用状況の監視

エンタープライズ利用では、管理者向け設定、利用状況の可視化、OpenTelemetry連携などを通じて、利用状況とコストを監視します。詳細は公式のMonitoring usageを参照してください。

↑ 目次に戻る

第3部:Claude Code Web版で使うOpus 4.7

14. Claude Code Web版とは何か

本記事では、公式ドキュメントで "Claude Code on the web" と呼ばれている機能を、日本語では「Claude Code Web版」と表記します。

Claude CodeにはCLI版だけでなく、ブラウザから使えるクラウド実行環境があります。公式ドキュメントUse Claude Code on the webによれば、Web版は claude.ai/code で動作し、Anthropicが管理するクラウドインフラ上で各セッションを実行します。リサーチプレビューとして提供されており、Pro / Max / Teamプラン、Enterpriseプランのpremium seatまたはChat + Claude Code seatで利用可能です。

なお、Web版はAnthropic管理のクラウド実行環境でコードを扱うため、企業利用ではリポジトリアクセス権限、GitHub Appの導入範囲、環境変数、ネットワークアクセス、PRコメントによる自動実行トリガーを事前に確認しておく必要があります。第15章以降で具体的な制御ポイントを見ていきます。

14.1 CLI版との違い

CLI版とWeb版の最大の違いは、実行場所とセッションの扱いです。

CLI版は「自分のマシンでエージェントを動かす」ツールです。Web版は「クラウドにエージェントを派遣する」ツールです。これは単なるUIの違いではなく、仕事の任せ方そのものが変わります。

CLI版は対話的なコーディングや、ローカル環境に強く依存するタスク(ローカルDB、ローカルの認証情報、プライベートな依存関係など)に向きます。Web版は明確なゴールを与えて自律実行させ、結果を後で確認する非同期的なワークフローに向きます。Opus 4.7の長時間自律実行性能は、Web版で特に活きます。

14.2 Web版で「使えるもの」「使えないもの」

公式ドキュメントが整理している「クラウドセッションで何が利用可能か」を、Opus 4.7を使う前提で再構成します。

クラウドセッションはリポジトリの新規クローンから始まります。リポジトリにコミットされているものはすべて利用できますが、ローカルマシンにしかない設定は持ち込まれません。

利用可能なもの

• リポジトリ直下の CLAUDE.md
• .claude/settings.json のhooks定義
• .mcp.json のMCPサーバー定義
• .claude/rules/、.claude/skills/、.claude/agents/、.claude/commands/
• .claude/settings.json で宣言したプラグイン(マーケットプレイスから自動インストール)

利用できないもの

• ユーザーレベルの ~/.claude/CLAUDE.md
• ユーザー設定の enabledPlugins
• claude mcp add で追加したMCPサーバー(ユーザー設定に書き込まれるため)
• ローカルのAPIトークンや静的な認証情報
• AWS SSOのような対話的なブラウザ認証

エンジニアリード視点で重要なのは、**「チームでWeb版を使うなら、すべての設定をリポジトリにコミットする運用に切り替える必要がある」**ということです。~/.claude/ に書いていた個人ルールも、チームで使うなら .claude/settings.json や CLAUDE.md に移し、レビュー対象にします。

14.3 プリインストールされている開発ツール

クラウドVMには主要な言語ランタイムとビルドツールがプリインストールされています。実務でよく使うものを整理します。

PostgreSQLとRedisはインストール済みですが、デフォルトでは起動していません。セッション内で service postgresql start のようにClaudeに頼んで起動させます。

正確なバージョンを確認したい場合は、セッション内でClaudeに check-tools を実行させると一覧が出ます。これはクラウドセッション専用のコマンドです。

14.4 リソース上限

公式ドキュメントが明示しているクラウドセッションのリソース上限は次の通りです(変更される可能性あり)。

• 4 vCPU
• 16 GBメモリ
• 30 GBディスク

大規模なビルドジョブやメモリを大量に使うテストはこの上限を超える可能性があります。それを超えるワークロードは、Remote Control機能で自分のハードウェア上でClaude Codeを動かす形になります。

エンジニアリードの判断材料としては、「この上限に収まるタスクはWeb版に任せ、それを超えるタスクはCLI版かRemote Controlに回す」という線引きになります。

↑ 目次に戻る

15. Web版を使い始める — GitHub連携と環境設定

15.1 GitHub認証の2つの方法

クラウドセッションはGitHubリポジトリにアクセスしてコードをクローンし、ブランチをプッシュします。認証方法は2通りあります。

両方とも有効です。Auto-fix(後述)を使う場合はGitHub Appが必須です。/web-setup で接続した後にAuto-fixを使いたくなったら、対象リポジトリにAppを追加でインストールします。

Team / Enterprise管理者は claude.ai/admin-settings/claude-code で /web-setup を無効化できます。Zero Data Retentionを有効にしている組織は、/web-setup を含むクラウドセッション機能を利用できません。

15.2 Environment(環境)の設定

Web版ではEnvironmentという単位でクラウド環境を管理します。Environmentにはネットワークアクセス権限、環境変数、セットアップスクリプトが紐づきます。

エンジニアリードがチームにWeb版を展開する際、最初に整備するのがEnvironmentです。具体的な作業項目は次のとおりです。

環境変数は .env 形式で書きます。1行に1つの KEY=value ペア、値をクォートで囲まない(クォートは値の一部として保存されてしまいます)。

NODE_ENV=development
LOG_LEVEL=debug
DATABASE_URL=postgres://localhost:5432/myapp

重要な注意点: 専用のシークレットストアはまだ用意されていません。環境変数とセットアップスクリプトはEnvironment設定として保存され、そのEnvironmentを編集できる人なら誰でも閲覧できます。本物の本番認証情報を入れるのは避け、ステージング環境やテスト用のキーに留めます。

15.3 セットアップスクリプト

Environmentにはセットアップスクリプトを設定できます。これは新しいクラウドセッションが開始する際、Claude Codeが起動する前に実行されるBashスクリプトです。

• 実行ユーザーはroot(Ubuntu 24.04)
• apt install などのパッケージインストールが可能
• スクリプトが非ゼロで終了するとセッション起動が失敗
• 致命的でないコマンドには || true を付けると安全

例　プリインストールされていない gh CLIを入れる場合

#!/bin/bash
apt update && apt install -y gh

15.4 Environmentキャッシング

セットアップスクリプトは最初の1回だけ実行され、以降はファイルシステムのスナップショットが再利用されます。これがWeb版の起動を高速に保つ仕組みです。

• 初回起動時にスクリプトが走る → ファイルシステムのスナップショットを取得
• 2回目以降のセッションは、スナップショットから起動 → スクリプト再実行なし
• 起動済みのプロセスはキャッシュされない(ファイルだけ)
• 約7日でキャッシュ失効、または環境設定変更時に再実行
• セッションを --resume で再開する場合はスクリプトは走らない

巨大なtoolchainのインストールやDockerイメージのpullをセットアップスクリプトに入れても、毎回起動が遅くなる心配はありません。

15.5 セットアップスクリプトとSessionStart hookの使い分け

両者は似ているようで役割が違います。実務で混同しやすいので整理します。

判断基準はシンプルです。

• 「クラウドにだけ必要なもの」(言語ランタイムやCLIツール) → セットアップスクリプト
• 「プロジェクトとして必要な準備」(npm install やDBマイグレーションなど、ローカルでも走るべきもの) → SessionStart hook

クラウドのみで動かしたいhookを書く場合、CLAUDE_CODE_REMOTE 環境変数(クラウドでは true)でガードを入れます。

#!/bin/bash
if [ "$CLAUDE_CODE_REMOTE" != "true" ]; then
  exit 0
fi
npm install
pip install -r requirements.txt

15.6 ネットワークアクセスの制御

クラウド環境の外向き通信は、Environment単位で4段階のアクセスレベルで制御します。

デフォルトはTrustedです。Trustedで許可されているドメインは公式ドキュメントに網羅されており、npm、PyPI、RubyGems、crates.io、Docker Hub、GCR、ECR、AWS、GCP、Azure、Sentry、Datadogなど、一般的な開発で使うドメインはほぼ含まれています。

社内のprivateレジストリなどを使いたい場合はCustomを選択し、Allowed domainsにドメインを列挙します。*.internal.example.com のようなワイルドカードも使えます。

エンジニアリードの観点では、ここはセキュリティポリシーの線引きに直結します。社内ネットワークやプロキシ経由でしかアクセスできないリソースに依存するタスクは、Web版よりCLI版(あるいはRemote Control)の方が向きます。

↑ 目次に戻る

16. ターミナルとWeb版を行き来する

CLI版とWeb版は別々のツールではなく、同じセッションを行き来できる連続体です。これがエンジニアリード視点で重要なポイントになります。

ターミナルからWeb版へ、Web版からターミナルへ、それぞれ移送する仕組みが用意されています。両方の機能を使うには、CLI版が同じclaude.aiアカウントでサインインしている必要があります。

16.1 ターミナルからWeb版へ — --remote

--remote フラグでターミナルから新しいクラウドセッションを起動できます。

claude --remote "Fix the authentication bug in src/auth/login.ts"

これでclaude.ai上に新しいクラウドセッションが作られ、現在のディレクトリのGitHubリモートを現在のブランチでクローンします。

ローカルにコミットしていない変更はVMに反映されないので、必要なら先にプッシュしておきます。VMはGitHubからクローンするのであって、自分のマシンからではないからです。

--remote でクラウドに送ったあとは、自分のターミナルでは別の作業を続けられます。並列で投げることもできます。

claude --remote "Fix the flaky test in auth.spec.ts"
claude --remote "Update the API documentation"
claude --remote "Refactor the logger to use structured output"

それぞれ独立したクラウドセッションとして並走します。/tasks コマンドで進捗を一覧できます。

エンジニアリード的な使い方としては、**「自分はターミナルで主要なコードを書きながら、付随する雑務を --remote でクラウドに振る」**というパターンが効きます。テスト修正、ドキュメント更新、小さなリファクタなど、注意を割きたくないが誰かにやってほしいタスクをクラウドに任せる感覚です。

16.2 ローカルでプランを立て、クラウドで実行する

複雑なタスクでは、ローカルでプランを立ててからクラウドで実行するという二段構えが有効です。

# 1. ローカルでplanモードに入る
claude --permission-mode plan

planモードでは、Claudeはファイルを読み、コマンドを実行して状況を調べ、ソースコードには触れずにプランを提案します。納得できるプランができたら、リポジトリにコミットしてプッシュ。

# 2. クラウドで実行
claude --remote "Execute the migration plan in docs/migration-plan.md"

このパターンは、戦略の決定権は人間が握り、実行はクラウドに任せる形になります。Opus 4.7の自律実行性能を活かしつつ、判断ミスのリスクを抑えられる構造です。エンジニアリードがチームに展開する際、推奨ワークフローとして示しやすい形でもあります。

「プランそのものをクラウドで作りたい」場合はultraplanを使います。Webセッションでプランを生成し、ブラウザでセクションごとにコメントを付けて改善し、納得したらクラウドで実行するか、プランをターミナルに送り返してローカル実行します。

16.3 GitHub連携なしのローカルリポジトリを送る

GitHubに接続していないリポジトリで claude --remote を実行すると、Claude Codeはローカルリポジトリをバンドルしてクラウドに直接アップロードします。バンドルにはすべてのブランチの履歴と、追跡対象ファイルの未コミット変更が含まれます。

GitHub接続済みでも強制的にバンドルを使いたい場合は CCR_FORCE_BUNDLE=1 を設定します。

CCR_FORCE_BUNDLE=1 claude --remote "Run the test suite and fix any failures"

制約:

• git リポジトリで、コミットが少なくとも1つ必要
• バンドルサイズは100 MB未満(超過時は自動的にカレントブランチのみ → 単一スカッシュスナップショットへフォールバック)
• 追跡されていないファイルは含まれない(git add してから送る)
• バンドルから作ったセッションはGitHubプッシュができない(GitHub認証も併用していれば可能)

GitLabやBitbucketのリポジトリをWeb版で扱いたい場合、この方法でクラウドに送れますが、結果のプッシュバックはできない点に注意が必要です。

16.4 Web版からターミナルへ — --teleport

クラウドで動いているセッションを、自分のターミナルに引き取って続きを書くこともできます。

# インタラクティブにセッションを選ぶ
claude --teleport

# セッションIDを直接指定
claude --teleport <session-id>

セッション内ですでにClaude Codeを動かしているなら、/teleport(/tp)でも同じことができます。/tasks でセッション一覧を出し、t キーを押してteleportすることも可能です。

teleportは**--resume とは別物**です。--resume はこのマシンのローカル履歴を再開するだけで、クラウドセッションには触れません。--teleport はクラウドセッションのブランチをチェックアウトし、会話履歴をすべてターミナルに引き取ります。

teleportの前提条件は次のとおりです

• 作業ディレクトリにコミットされていない変更がない(あればstashプロンプトが出る)
• 同じリポジトリのチェックアウトから実行している(forkではダメ)
• セッションのブランチがリモートにプッシュ済み
• 同じclaude.aiアカウントで認証されている

エンジニアリード視点での使い方は、**「クラウドが大方やってくれた仕事を、最後の微調整だけターミナルで詰める」**というワークフロー。たとえば、CIで失敗していた問題をクラウドが直してくれたあと、--teleport で自分の手元に持ってきて、コミットメッセージを書き直してpushする、といった具合です。

逆方向(ローカル → Web)への送出はコマンドラインからは現在サポートされていません。Desktopアプリの「Continue in」メニューが提供されています。

↑ 目次に戻る

17. Web版でのセッション運用

17.1 セッションの永続性とモバイル監視

Web版の最大の強みのひとつが、セッションの永続性です。ブラウザを閉じても、ノートPCを閉じても、クラウドのセッションは動き続けます。

監視方法は3つあります。

• ブラウザでclaude.ai/codeを開く
• Claudeモバイルアプリを開く
• ターミナルで /tasks を実行(CLI版がサインイン済みの場合)

エンジニアリード視点で意味を持つのは、**「自分が会議に入っている間、Claudeにコードを書かせ続けられる」**という点です。30分の会議の前に claude --remote "..." を投げて、会議が終わった頃に結果を確認する、というワークフローが成立します。

17.2 コンテキスト管理

Web版でもCLI版と同じく、セッション内のコンテキスト管理が重要です。Web版で使えるビルトインコマンドは限定的です。

コンテキストウィンドウが容量に近づくと自動圧縮が走ります。これはCLI版と同じ挙動で、デフォルトは約95%でトリガーされます。早めに圧縮させたい場合は、Environment変数に CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=70 のように設定すれば、70%で圧縮を始めるよう調整できます。

17.3 変更内容のレビュー

各セッションには +42 -18 のようなdiffインジケーターが表示されます。クリックするとdiffビューが開き、特定の行にインラインコメントを残せます。次のメッセージでClaudeにコメントが渡され、修正を依頼できます。

このフローは、エンジニアリード視点では「コードレビューをそのまま指示に変える」体験になります。GitHub PRレビューと同じ感覚で、コメントが直接Claudeへのフィードバックになる、という流れです。

セッションから直接PRを作成することもできます。詳細は公式のReview and iterateガイドを参照してください。

17.4 セッション共有

Web版のセッションはチームで共有できます。共有設定はアカウント種別で異なります。

Enterprise / Teamでは、受信側のアカウントに紐づいたGitHubアカウントでリポジトリアクセス検証がデフォルトで有効です。Max / Proではこの検証はデフォルト無効なので、共有前に内容を確認します(プライベートリポジトリのコードや認証情報が含まれる可能性があるため)。

Slack連携経由のセッションは自動的にTeam可視性で共有されます。

エンジニアリードがチームでセッション共有を活用するなら、**「困ったタスクをセッション共有で渡す」**というパターンが有効です。新メンバーがハマっているバグを、自分のセッションで原因まで調べてからセッションURLを渡す、という流れがそのまま再現できます。

17.5 Auto-fix — PRを見守らせる

これはWeb版でしか使えない機能で、なかなか強力です。

ClaudeにプルリクエストをWeb版で監視させ、CI失敗やレビューコメントに自動対応させられます。

仕組み:ClaudeはPRのGitHubイベントを購読し、CIチェック失敗やレビューコメントが入るたびに調査して、明確な修正があればプッシュします。

判断基準

• 明確な修正 → 修正してプッシュし、セッションで何をしたか説明
• 曖昧な依頼 → 解釈が複数ある場合や設計上重要な変更の場合は、人間に確認
• 重複・無対応で済むイベント → セッションにメモして次へ

Auto-fixを有効にする方法は複数あります:

• Web版で作成したPR:CIステータスバーからAuto-fixを選択
• ターミナルから:PRのブランチで /autofix-pr を実行
• モバイルアプリから:Claudeに「このPRを見張って修正してください」と頼む
• 既存のどんなPRでも:PRのURLをセッションに貼って指示

Auto-fixはGitHub Appが必須です(PR webhookを受信するため)。

注意点:Auto-fixがPRコメントに返信する際、ユーザー名はあなたのGitHubアカウントとして表示されます(個別のラベルでClaude Code経由とは識別されます)。Atlantis、Terraform Cloud、issue_comment で発火するGitHub Actionsなど、コメント駆動の自動化を使っているリポジトリでは、Claudeのコメントがそれらを起動する可能性があります。インフラデプロイや特権操作をPRコメントで実行できる仕組みがあるリポジトリでは、Auto-fixを有効にする前にレビューが必要です。

エンジニアリードとしては、「Auto-fixを許可するリポジトリの線引き」をチーム方針として決めておくのが安全です。アプリケーションコードのPRはOK、インフラリポジトリはNG、というポリシーを明文化しておく形です。

17.6 アーカイブと削除

セッションが増えすぎたら整理できます。

• アーカイブ:サイドバーで対象セッションをホバーしてアーカイブアイコン。デフォルトのリストから消えるが、フィルタで表示可能
• 削除:アーカイブ済みセッションのリストからホバーして削除アイコン、またはセッションを開いてタイトル横のドロップダウンからDelete

削除は取り消せません。

↑ 目次に戻る

18. Web版でOpus 4.7を活かすコーディング作法

ここまでがWeb版の機能解説です。最後に、Opus 4.7をWeb版で使う際のコーディング実務上の作法をまとめます。エンジニアリードとしてチームに教える際にも、自分で手を動かすときにも使える形で整理します。

18.1 タスクの粒度設計

Web版に投げるタスクは、CLI版で対話しながら進めるタスクとはちょうどいい大きさが違います。Web版は途中で口を出すのにひと手間かかるので、1つのセッションで1つのタスクが完結するくらいの大きさに揃えるのが現実的です。

向いているタスクの例

• 機能を1つだけ実装する(APIエンドポイントを足す、フォームのバリデーションを足す、など)
• CIで落ちている1つのテストを直す
• ドキュメントを更新する(README、APIリファレンス、変更ログなど)
• 特定のモジュールだけをリファクタリングする
• 依存ライブラリをアップデートして、それに伴う修正をする
• テストカバレッジを増やす

向いていないタスクの例

• どう作るか決まっていない、探索しながら進めるような開発(planモードと組み合わせれば可能)
• 本番の認証情報が必要なタスク
• ローカルにあるコミットしていない変更を前提とするタスク
• VMのリソース上限を超えそうな重いビルド

18.2 初回プロンプトの書き方(Web版仕様)

第2部第8.1節で紹介した「依頼書スタイル」はWeb版でも基本になりますが、Web版ではこれにいくつか項目を足します。

[目的]
ユーザー認証APIをOAuth 2.0ベースに作り変える。

[守ってほしいこと]
- 既存のセッション管理ロジック(src/auth/session.ts)は触らない
- 段階的に移行し、既存の認証エンドポイントとの互換性は保つ
- TypeScriptのstrictモードは外さない

[完了の条件]
- 既存テスト(tests/auth/)がすべてパスすること
- 新しいOAuthフロー用のE2Eテストが追加されていること
- README.mdの認証セクションが更新されていること

[見てほしいファイル]
- src/auth/*.ts
- tests/auth/*.test.ts
- README.md

[ブランチ運用]
- 現在のブランチから派生させ、`feature/oauth-migration` という名前にする

[PR作成について]
- 完了したらPRを作る
- PR本文に、このセッションへのリンクを貼っておく

Web版で特に大事なのが最後の2項目です。Web版はクラウドのVMの中だけで作業が完結するので、ブランチを切るところからPRを作るところまで、最初のお願いの中に書いておくと、人間があとから介入する手間が減ります。

PR本文にセッションリンクを入れる運用は公式でも推奨されています。レビュアーが「このPRはどのセッションから生まれたんだろう?」と気になったとき、リンクから元の作業をたどれるようになります。Claudeにセッションリンクを作ってもらうときは、この1行で済みます。

echo "https://claude.ai/code/${CLAUDE_CODE_REMOTE_SESSION_ID}"

CLAUDE_CODE_REMOTE_SESSION_ID という環境変数は、クラウドセッションの中だと自動でセットされています。

18.3 4.6時代の補助的な指示はWeb版でも外す

第1部・第2部で繰り返し書いた通り、Opus 4.7では「念のため確認して」「進捗をこまめに報告して」のような補助的な指示は外します。Web版では特にこの方針が効きます。

理由はシンプルです。Web版が想定している「ブラウザを閉じても動き続ける長時間タスク」では、そもそも人間がそばで見張っている前提を捨てているからです。Claudeが自分で動作を検証し、自分で進捗を報告し、迷ったら自分で止まる。この挙動を信じて任せる設計が必要になります。

CLAUDE.mdにチーム共通のルールとして書くなら、4.7向けにはこんな書き方が合います。

# 開発のガイドライン

## 作業の進め方
- これはクラウドセッションで動く、長時間の自律タスクです。
- 大きな変更を加えたら、そのつどテストを走らせて動作を確かめてください。
- 仕様が本当にどちらとも取れる場合だけ、手を止めて質問してください。それ以外は自分で判断して進めて構いません。
- 途中の細かいステップごとに、人間に確認を取る必要はありません。

18.4 並列実行を活かす

Web版の構造的な強みが、複数のタスクを同時に走らせられることです。CLI版で同じことをやろうとすると、ターミナルを複数立ち上げて、それぞれの権限プロンプトに答えて……と手間がかかります。Web版なら --remote を3回叩くだけで、3つのクラウドセッションが同時に動き始めます。

Opus 4.7はsubagentをデフォルトでは控えめにしか起動しません。そのため、Web版で大規模に並列処理したい場合は、**「--remote を何回か叩いて、独立したタスクとして並走させる」**ほうが、subagentを明示的に指示するより素直なやり方です。それぞれ別のVM、別のコンテキスト、別のブランチで動くので、お互いに干渉する心配もありません。

向いている例

• 複数のレガシーモジュールを並行して移行する
• 複数のサービスにセキュリティパッチを当てて回る
• 複数言語の翻訳ファイルをまとめて更新する
• ジャンル別のテストを並行で直す

/tasks で全セッションの進み具合を一覧で確認し、終わったものから順に手元に引き取る(teleport)か、レビューに回します。

18.5 1Mコンテキストの恩恵

Opus 4.7で標準価格になった1MコンテキストはWeb版で特に効きます。クラウドVMはリポジトリをまるごとクローンしたところから始まるので、リポジトリ全体をClaudeに読ませる前提のタスクが現実的になります。

具体例はこんな感じです。

• 数百ファイルにまたがるリファクタリング(命名規則を揃える、APIを移行する、など)
• 複数のサブシステムをまたぐ依存関係の調査
• レガシーコードベース全体を読んだうえで、段階的に作り直す
• リポジトリ全体のセキュリティ監査

第2部第10章で触れた [1m] サフィックスや、opusplan の落とし穴(1Mに自動アップグレードされない)は、Web版でも同じです。

18.6 うまくいかなかったときの動き方

Web版のセッションがうまくいかなかったとき、人間の動き方はCLI版と少し違います。

セッションの中でできることは限られています(ターミナルで対話的に探るような動きができないため)。代わりに次の選択肢があります。

1. diffビューの気になる行にコメントを残し、次のメッセージで指示を出す:Web版で軌道修正する一番自然なやり方
2. /compact で会話履歴を要約してから、別のアプローチを指示する:暴走しかけたセッションを、リセットせずに引き継ぎたいとき
3. --teleport でターミナルに引き取って、自分の手で直す:Claudeがループから抜けられなくなったり、対話的なデバッグが必要になったとき
4. そのセッションは諦めて、もっと良いプロンプトで新しいセッションを作る:そもそも方針自体が違ったとき

エンジニアリードの目線で言うと、**「Web版のセッションは安いし、並列でいくらでも走らせられる。粘らないで切り替える判断も大事」**というのが現場感覚です。Opus 4.7が変な方針のまま長く動き続けるよりは、新しいセッションで仕切り直したほうが結果的に速いことが多いです。

18.7 チームに広げるかどうかの判断材料

ここまでが18章の各論ですが、最後にチームへの展開をどう判断するかをまとめておきます

ただ、その判断の前にもっと大事な前提を一つ書いておきます。

Claude Codeは、動作環境と直結させて、その場で検証させながら進めるのが大原則です。

これはCLI版・Web版どちらを選ぶかの議論より前に来る話です。Claudeに依頼を投げて「たぶんいい感じに直してくれているだろう」と放置していると、コンパイルすら通っていないコードが量産される、テストが落ちたまま完了報告される、見た目が壊れたUIが「直しました」と返ってくる、ということが普通に起こります。Opus 4.7は4.6より自己検証する傾向が強くなったとはいえ、検証手段が手元に用意されていなければ、Claudeも検証のしようがありません。

具体的には、こういう状態を作っておくのが基本です。

• コードを書いたら、すぐビルド・テストを走らせる:Claudeが変更を加えるたびに npm test や cargo test、pytest が動く状態にしておく
• APIを直したら、すぐ叩いてみる:ローカルのサーバーを立ち上げておいて、curl やテストクライアントで実際にレスポンスを確認する
• DBを触ったら、実データで動かしてみる:開発用DBに接続して、クエリが通るか、想定どおりのデータが返ってくるかを確認する
• UIを直したら、ブラウザで実際に表示する:Playwright系のMCPやClaude in Chromeで、見た目とインタラクションを確認する
• エラーが出たら、ログを直接読ませる:推測で対処させるのではなく、実際のスタックトレースやサーバーログをClaudeに見せて原因を切り分けさせる

このループを回せるかどうかが、Claude Codeで成果が出るチームと出ないチームの分かれ目になります。「依頼書を書いて、結果を見る」だけのワークフローでは、いずれ品質が崩れます。

この前提に立つと、CLI版が基本になる

動作環境と直結させて検証させながら進める、という原則を置くと、CLI版を中心にすべき理由が自然に出てきます。CLI版でしかできない、もしくはCLI版のほうが圧倒的にやりやすいことが多いからです。

• ローカルDBに直接つなげる:開発用のPostgreSQLやMySQLが手元で動いていれば、Claudeにスキーマを読ませたり、実データでクエリを試させたり、マイグレーションを当てて結果を確認させたりが普通にできます。Web版だとクラウドVMからローカルのDBは見えないので、検証用データを別途用意したり、本番に近い環境を再構築したりという余分な手間がかかります。
• MCP経由でChromeを操作させられる:Claude in Chrome やPlaywright系のMCPと組み合わせれば、実際のブラウザでフロントを動かして、見た目を確認しながら直してもらえます。「画面で確認しないと分からない」種類のバグでは、これがあるかないかで作業の質がまるで違います。
• ローカルにしかないリソースが使える:社内ネットワーク経由でしか叩けないAPI、VPN越しの検証環境、ローカルのDocker Composeで立ち上げた一式、~/.aws/credentials のような認証情報。こういうものを巻き込んで動作検証できるのはCLI版だけです。
• 書いたコードをすぐ自分の目で確かめられる:エディタ、ブラウザのプレビュー、ホットリロード、デバッガ。普段使っている開発体験をそのまま活かして、Claudeの変更を即座に検証できます。
• 新機能がCLI版から先に来る:Claude Codeの新機能は、基本的にCLI版に先に入って、しばらくしてからWeb版にも来る、というリリースパターンです。最新機能を早く触りたいならCLI版です。
• 権限やhookを細かくコントロールできる:.claude/settings.local.json で個人ごとに調整したり、hookで特定のコマンドの前後に処理を挟んだり、設定の自由度はCLI版のほうが高いです。

要するに、CLI版は 「Claudeを自分の開発環境の中に住まわせて、自分の目の前で動作検証させながら進める」 ためのツールです。

Web版を積極的に使うといいケース

一方で、CLI版の小回りが要らない場面では、Web版のほうが圧倒的に楽です。Web版の魅力は性能の高さでも機能の豊富さでもなく、**「とにかく楽」**という一点に尽きます。

• 複数セッションを同時に走らせるのがとにかく楽:CLI版で並列実行しようとすると、ターミナルを複数開いて、それぞれの権限プロンプトに答えて、進捗をタブ間で見比べて……と地味に手間がかかります。Web版なら --remote を3回叩くか、ブラウザでセッションを3つ開くだけで終わりです。複数タスクを並列で進めたいときの「楽さ」は、Web版が頭ひとつ抜けています。
• ブラウザを閉じても作業が進む:長時間タスクをWeb版に任せて、自分はノートPCを閉じて移動する、会議に出る、別の仕事をする、ということができます。
• GitHubへのプッシュやPR作成までお任せにできる:ブランチを切ってコミットしてプッシュしてPRを作る、という一連の流れを、自分の手でやらずにWeb版に任せたいときに便利です。CLI版でも同じことはできますが、Web版はGitHub周りが最初から組み込まれていて、認証も含めて手間が少ないです。
• 動作検証が「ビルド + テスト」で完結する作業:バックエンドのリファクタリング、CI修正、ドキュメント更新、依存関係のアップデート。クラウドVMの中でビルドして、テストを走らせて、それで品質が担保できるタイプの作業は、Web版の得意分野です。逆に言うと、ローカルDBや実ブラウザでの確認が必要な作業はWeb版では検証しきれない、ということでもあります。
• リポジトリの中だけで話が完結する:ローカルの何かに依存しない、リポジトリ内のコードとテストだけで完結するタスクなら、Web版に投げて困ることはほとんどありません。
• 非同期で進める働き方が受け入れられる文化がある:「投げて、しばらく経ってから結果を見る」というリズムが合うチームなら、Web版の良さを引き出しやすいです。

Web版を選ぶときの注意点

• ローカル環境での動作検証が必要な作業はWeb版では完結しません
• ローカルDB、ローカルブラウザ、社内ネットワーク内のリソースに依存する作業も同様です
• リソース上限(4 vCPU / 16 GB / 30 GB)を超える重いビルドやテストは、そもそもWeb版で動きません
• セルフホストのGit(GitHub Enterprise Server以外のGitLab、Bitbucketなど)中心のチームは、Web版の恩恵を受けにくいです

現実的な始め方

ここまでをまとめると、CLI版を主役にして自分の開発環境の中で動作検証しながら進める。並列で走らせたい雑務だけWeb版に振るというのが、いちばん安全で効果が出やすいやり方です。

たとえばこんな使い分けが現実的です。

• 自分は手元のCLI版で主要な実装を進める。ローカルDB、ブラウザ、テストランナーをすべて巻き込んで、その場で動作検証させながら進める
• 並行して走らせたい雑務(明らかな小規模リファクタ、ドキュメント更新、CIで落ちている既知のテスト修正など)は --remote でクラウドに振る
• クラウドのセッションが終わっていたら、--teleport で手元に引き取って、最後の動作確認だけ自分の環境でやる

この使い分けに慣れてくると、「これは動作検証が手元で必要だからCLI版」「これはビルド+テストで足りるからWeb版」の感覚が自然と身につきます。チーム展開もこの段階から始めるのが無理がないです。

↑ 目次に戻る

まとめ

ここまで、Claude Opus 4.7のモデル仕様、Claude Code CLI版での実践ノウハウ、Claude Code Web版の使い方を、公式情報をもとに見てきました。最後に、全体を通しての要点を簡潔にまとめます。

Opus 4.7で最も大きく変わったのは、性能そのものよりもモデルの振る舞いです。命令を字面通りに解釈し、必要なときだけ深く考え、自発的に進捗を報告し、自分の出力を検証する。このモデルを最大限活用するには、人間側のインタラクションパターンを変える必要があります。公式が繰り返し強調しているメッセージは、「ペアプログラマーとして一行ずつ指導するのではなく、業務を委譲する有能なエンジニアとして扱う」という一点に集約されます。

実務上の要点は5つです。

まず、初回プロンプトに依頼の全情報を集約すること。意図、制約、完了条件、関連ファイルを最初に渡し、途中介入を最小限に抑えます。これがトークン効率と品質の両方を最大化します。

次に、4.6時代の補助的な指示を外して再評価すること。「念のため確認して」「進捗を報告して」「ダブルチェックして」のような指示は、4.7では自発的に行われるか、字面通りに過剰反応するかのどちらかになります。公式が「外せ」と明示している補助的な指示は、いったん外してから再評価するのが基本ラインです。

そして、effortレベルを意識的に選ぶこと。CLI版では xhigh をデフォルトとし、用途に応じて切り替えます。max は必要以上に考え込むリスクがあるため意図的にのみ使い、コスト重視の作業では medium や high に下げます。

さらに、1Mコンテキストの活用と注意点を理解すること。Max / Team / EnterpriseプランのClaude Codeでは自動でアップグレードされ、追加プレミアムは付きません。一方で opusplan には適用されない、トークン消費は当然増える、といった点を踏まえてアーキテクチャを設計します。

最後に、CLI版とWeb版を連続体として使うこと。対話的な作業や手元の検証はCLI版、明確なゴールがある自律実行と並列タスクはWeb版、というのが基本線です。--remote でクラウドにタスクを送出し、--teleport で手元に引き戻す、という行き来がOpus 4.7の自律実行性能を最大限に引き出します。

APIを直接利用している場合は、これに加えてMessages APIの破壊的変更(temperature などのsamplingパラメータ禁止、固定thinking budgetの廃止、prefillの廃止、新トークナイザーによるトークン消費の増加)への対応が必要です。Claude Managed Agentsを利用している場合は、モデルIDの更新だけで移行が完了します。

これらの指針はすべて、Anthropicの公式ドキュメントに基づいています。本記事で参照した主要な情報源は次の通りです。

仕様や挙動は今後も更新される可能性があるため、最終的な判断は常に最新の公式ドキュメントを参照することをお勧めします。本記事が、Opus 4.7を業務で活用する際の判断材料として役立てば幸いです。

↑ 目次に戻る

こんにちは、Qualitegコンサルティングです！

サブスクリプションビジネスの完全ガイド　第3回　をお届けいたします！
今回は、 PLG・SLG、ユニットエコノミクス、データ改善の実務ポイントについて解説していきたいとおもいます！

この記事でわかること

　・PLG・SLG・ランドアンドエクスパンドの違いと使い分け
　・NRR、LTV/CAC、ペイバック期間など主要指標の実務的な読み方
　・バーンレートとランウェイから資金繰りリスクを把握する方法
　・ファネル分析・コホート分析・A/Bテストによる改善の進め方
　・AIプロダクト特有の原価構造とユニットエコノミクスの注意点

サブスクビジネス完全攻略 シリーズ一覧

第１回　『アープがさぁ...』『チャーンがさぁ...』にもう困らない

サブスクビジネス完全攻略 第1回～『アープがさぁ...』『チャーンがさぁ...』にもう困らない完全ガイド

なぜサブスクリプションモデルが世界を変えているのか、でもAI台頭でSaaSは終わってしまうの？ こんにちは！ Qualitegコンサルティングです！ 新規事業戦略コンサルタントとして日々クライアントと向き合う中で、ここ最近特に増えているのがSaaSビジネスに関する相談です。興味深いのは、その背景にある動機の多様性です。純粋に収益モデルを改善したい企業もあれば、 「SaaS化を通じて、うちもデジタルネイティブ企業として見られたい」 という願望を持つ伝統的な大企業も少なくありません。 SaaSという言葉が日本のビジネスシーンに本格的に浸透し始めたのは2010年代前半。それから約15年が経ち、今やSaaSは「先進的な企業の証」のように扱われています。 まず SaaSは「サーズ」と読みます。 （「サース」でも間違ではありません、どっちもアリです） ほかにも、 MRR、ARR、アープ、チャーンレート、NRR、Rule of 40…… こうした横文字が飛び交う経営会議に、戸惑いながらも「乗り遅れてはいけない」と焦る新規事業担当者の姿をよく目にします。 しかし一方で、2024

Qualiteg BlogQualiteg コンサルティング

第２回　「解約率5%」が1年後に半分の顧客を消す恐怖と、それを防ぐ科学

サブスクビジネス完全攻略 第2回～「解約率5%」が1年後に半分の顧客を消す恐怖と、それを防ぐ科学

こんにちは！ Qualitegコンサルティングです！ 前回の第1回では、サブスクリプションビジネスの基本構造と、LTV・ユニットエコノミクスという革命的な考え方を解説しました。「LTV > 3 × CAC」という黄金律、覚えていますか？ サブスクビジネス完全攻略 第1回～『アープがさぁ...』『チャーンがさぁ...』にもう困らない完全ガイドなぜサブスクリプションモデルが世界を変えているのか、でもAI台頭でSaaSは終わってしまうの？ こんにちは！ Qualitegコンサルティングです！ 新規事業戦略コンサルタントとして日々クライアントと向き合う中で、ここ最近特に増えているのがSaaSビジネスに関する相談です。興味深いのは、その背景にある動機の多様性です。純粋に収益モデルを改善したい企業もあれば、 「SaaS化を通じて、うちもデジタルネイティブ企業として見られたい」 という願望を持つ伝統的な大企業も少なくありません。 SaaSという言葉が日本のビジネスシーンに本格的に浸透し始めたのは2010年代前半。それから約15年が経ち、今やSaaSは「先進的な企業の証」のように扱われています。

Qualiteg BlogQualiteg コンサルティング

さて、前回までの記事では、サブスクリプションビジネスの基本概念（LTV、CAC、ユニットエコノミクス）と、顧客獲得の方法（広告と自然流入）、そして重要指標（MRR、チャーン率、CVR、ARPU）について解説してきました。

今回の第3回では、実際に顧客を獲得してから成長させ、データに基づいて改善していくフェーズに焦点を当てます。指標を理解するだけでは不十分で、それをどう経営判断に活かすかが重要です。特に、生成AIプロダクトの領域では、従来のSaaS指標の読み方に加えて、AI特有のコスト構造や業務定着の難しさを踏まえた設計が求められます。そうした視点も交えながら解説していきます。

第5章：成長戦略の選択

～PLGとSLG、そして統合アプローチ～

PLG（プロダクト主導型成長）：プロダクトの力で成長する

PLG（Product-Led Growth：プロダクト主導型成長）は、営業やマーケティングではなく、プロダクト自体の力で成長する戦略です。近年急成長したSaaS企業の多くがこの戦略を採用しており、コミュニケーションツール、ビデオ会議ツール、ドキュメント作成ツールなどの領域で成功例が多く見られます。

PLGの最大の特徴は、顧客が自分でサービスを見つけ、試し、価値を感じ、購入まで進むことです。営業担当者と話すことなく、クレジットカードを登録して使い始められます。これにより、顧客獲得コストを大幅に削減できます。営業担当者の人件費がかからないだけでなく、顧客も自分のペースで検討できるため、購買体験が向上します。

PLGが成功するには、いくつかの条件があります。まず、プロダクトが直感的で使いやすいことです。マニュアルを読まなくても、触っているうちに使い方が分かる必要があります。複雑な機能を持つツールであっても、テンプレートや分かりやすい初期画面を用意することで、初心者でもすぐに使い始められる設計が求められます。

次に、個人でも価値を感じられることです。最初は一人で使っても何らかの価値があり、その後チームメンバーを招待することで、さらに大きな価値を生み出す。このように、小さく始めて大きく育てられる設計が重要です。

口コミで広がる仕組みもPLGの重要な要素です。たとえばビデオ会議ツールでは、会議に参加する側はアカウント登録が不要な設計にすることで、招待された人が「これは便利だ」と感じ、自分も使い始めるという好循環が生まれます。

PLGでは、フリーミアムモデルまたは無料トライアルモデルを採用することが一般的です。フリーミアムは、基本機能を永続的に無料で提供し、高度な機能を有料にするモデルです。無料トライアルは、全機能を期間限定（通常14日か30日）で提供するモデルです。どちらを選ぶべきかは、プロダクトの特性と対象顧客によって変わります。

SLG（営業主導型成長）：営業の力で成長する

SLG（Sales-Led Growth：営業主導型成長）は、営業チームが主導して顧客を獲得する伝統的な戦略です。エンタープライズ向けのSaaS企業の多くがこの戦略を採用しています。

SLGが適しているのは、単価が比較的高く、導入判断に説明や調整が必要な場合です。たとえば月額数万円から数十万円以上のBtoBサービスでは、費用対効果、セキュリティ、既存システムとの連携、運用体制などを確認したうえで意思決定されることが多くなります。こうしたプロセスでは、人による説明と説得が欠かせません。

意思決定に複数の関係者が関わる場合も、SLGが有効です。大企業では、現場の担当者、IT部門、調達部門、決裁者など、さまざまな人を巻き込む必要があります。それぞれの関心事や懸念に対応し、全員を納得させるには、営業担当者の調整力が必要です。

SLGの営業プロセスは、一般的に次のような流れになります。まず、マーケティングチームがMQL（Marketing Qualified Lead：マーケティング施策で獲得した見込み客）を獲得します。ホワイトペーパーのダウンロード、ウェビナーへの参加、デモリクエストなどがきっかけです。次に、インサイドセールスチームがMQLを評価し、有望なものをSQL（Sales Qualified Lead：営業対応すべき見込み客）に昇格させます。そして、フィールドセールスチームがSQLに対して、デモ、提案、交渉を行い、契約まで導きます。

SLGで重要なのは、営業効率を測る指標です。たとえば「マジックナンバー」という指標があり、四半期の新規ARRを前四半期の営業・マーケティング費用で割って計算します（この指標の基準値は企業や業界によって解釈が異なるため、自社の事業特性に合わせて評価するのが望ましいとされています）。たとえば、前四半期に営業・マーケティングに1億円投資し、今四半期に新規ARR8,000万円を獲得したら、マジックナンバーは0.8となります。

ランドアンドエクスパンド：小さく始めて大きく育てる

ランドアンドエクスパンドは、PLGとSLGの良いところを組み合わせた戦略です。最初は小さな契約から始め、徐々に拡大していきます。

典型的なシナリオはこうです。まず、一つの部署や小さなチームで試験導入してもらいます。月額5万円程度の小さな契約です。この段階では、決裁権限も低く、スピーディーに導入できます。数ヶ月後、成果が出始めると、他の部署も興味を持ち始めます。「営業部で使っているあのツール、マーケティング部でも使えないか」という声が上がります。半年後には全社導入の検討が始まり、月額100万円の契約に拡大します。1年後にはグループ会社にも展開し、月額500万円規模の契約に成長することもあります。

この戦略の利点は、顧客側の導入リスクを抑えられることです。いきなり全社導入するよりも、小規模な試験導入から始めるほうが、失敗時の影響を限定できます。また、実際に使ってみて価値を実感してから拡大するので、導入の成功率も高くなります。

ランドアンドエクスパンドを成功させるには、最初の成功体験が決定的に重要です。最初の部署で確実に成果を出し、社内でサクセスストーリーを作ることが重要です。そのためには、カスタマーサクセスチームが積極的に支援し、ベストプラクティスを提供する必要があります。

プロダクトの設計も重要です。小規模から始められるが、大規模にも対応できる拡張性が必要です。ユーザー数が10人から1,000人に増えてもパフォーマンスが劣化せず、部署ごとの権限管理ができ、他のシステムと連携できる。こうした企業導入に耐えうる機能が求められます。

NRR（純収益継続率）：既存顧客の成長力を測る

NRR（Net Revenue Retention：純収益継続率）は、既存顧客からの収益がどれだけ維持・成長しているかを示す指標です。新規顧客を除いて、既存顧客だけでどれだけ成長できるかを測ります。

NRRの計算方法を具体的に見てみましょう。期初（たとえば2024年1月）の既存顧客からの月間収益が1,000万円だったとします。1年後（2025年1月）、同じ顧客群からの収益を測定します。一部は解約し、一部はダウングレードしていますが、多くはアップグレードしています。結果、1,150万円になっていたとすると、NRRは115%です。

NRRが100%を超えているということは、新規顧客を一人も獲得しなくても、既存顧客だけで成長できるということです。これは投資家が重視する指標の一つで、優良なSaaS企業ではNRRが120%前後に達するケースも報告されています（具体的な基準値は業界や企業規模によって異なります）。

NRRを高めるには、いくつかの方法があります。まず、チャーン（解約）を減らすことです。解約が減れば、それだけNRRは向上します。次に、アップセルを増やすことです。顧客の利用状況を分析し、適切なタイミングで上位プランを提案します。そして、クロスセルで収益を増やすことです。関連製品やアドオン機能を追加購入してもらいます。

NRRが高い企業には共通点があります。それは、顧客の成功に本気でコミットしていることです。顧客がビジネス目標を達成し、成長すれば、自然とサービスの利用も増えます。逆に、顧客のビジネスが停滞すれば、サービスも不要になります。だからこそ、カスタマーサクセスが重要なのです。

第5章のまとめ——実務での判断軸

ここまでPLG、SLG、ランドアンドエクスパンド、NRRを見てきましたが、重要なのは、PLGかSLGかを二択で考えることではありません。特にBtoB SaaSやAIプロダクトでは、最初の接点はプロダクト主導で生まれても、本格導入ではセキュリティ、権限設計、既存業務との接続、費用対効果の説明が必要になります。つまり、成長戦略は「売り方」だけでなく、「導入後に価値が定着する構造」まで含めて設計する必要があります。

特に生成AIプロダクトの場合、セルフサービスで試しやすくする一方で、本番運用ではプロンプト設計、データ連携、出力品質の監視、ガバナンス対応といった領域で支援が必要になります。NRRを伸ばす鍵も、新機能の追加よりも、顧客の業務にどれだけ深く定着するかにあります。Qualitegでは、こうした「導入から定着までの設計」を、プロダクト設計と並行して伴走する形で支援しています。

第6章：キャッシュフローの罠を避ける

～資金繰りとユニットエコノミクス～

バーンレートとランウェイ：生存期間を把握する

スタートアップにとって、現金は事業継続の生命線です。どんなに将来性があっても、現金が尽きれば事業は続けられません。バーンレートは、毎月どれだけ現金を消費しているかを示す指標で、ランウェイは、今のペースで何ヶ月事業を継続できるかを示します。

バーンレートには、グロスバーンとネットバーンの2種類があります。グロスバーンは、毎月の総支出額です。オフィス家賃、人件費、サーバー代、マーケティング費用など、すべての支出を含みます。たとえば、月間支出が500万円なら、グロスバーンレートは500万円です。

ネットバーンは、総支出から収益を引いた額です。月間支出が500万円でも、収益が200万円あれば、ネットバーンレートは300万円です。これが実際に減っていく現金の額です。

ランウェイは、現金残高をネットバーンレートで割って計算します。現金残高が3,000万円で、ネットバーンレートが300万円なら、ランウェイは10ヶ月です。つまり、今のペースだと10ヶ月後に資金が尽きるということです。

一般的に、スタートアップは常に12〜18ヶ月分のランウェイを確保しておくべきとされています。なぜなら、資金調達には通常3〜6ヶ月かかるため、ランウェイが6ヶ月を切ってから動き出しても間に合わない可能性が高いからです。また、資金調達の交渉において、ランウェイが短いと足元を見られ、不利な条件を受け入れざるを得なくなります。

ペイバック期間：投資回収の時間軸

ペイバック期間は、顧客獲得コスト（CAC）を回収するまでの期間です。サブスクリプションビジネスのキャッシュフローを理解する上で極めて重要な指標です。

計算方法はシンプルです。CACを月間の粗利益で割ります。たとえば、CACが30,000円で、月間ARPUが5,000円、粗利益率が60%の場合、月間粗利益は3,000円です。ペイバック期間は30,000円÷3,000円＝10ヶ月になります。

なぜ粗利益で計算するかというと、売上から直接原価（サーバー代、決済手数料、AIプロダクトであれば推論コストなど）を引いた額が、実際に手元に残るお金だからです。売上が5,000円でも、原価が2,000円かかれば、実際には3,000円しか残りません。

ペイバック期間が重要な理由は、キャッシュフローに直結するからです。ペイバック期間が12ヶ月ということは、顧客を獲得してから1年間は投資分が回収できていないということです。100人獲得すれば、1年間は100人分の未回収コストを抱えることになります。成長すればするほど、キャッシュが必要になるのです。

業界のベンチマークとして、BtoB SaaSではペイバック期間12ヶ月以内が一つの目安とされ、6〜9ヶ月であれば健全、6ヶ月未満なら非常に効率的と評価されることが多いようです（具体的な基準は事業モデルや顧客セグメントによって異なります）。BtoCの場合は、さらに短く、3〜6ヶ月が一つの目安とされます。BtoCのほうが短い理由は、チャーン率が相対的に高く、長期間かけて回収するリスクが大きいからです。

ペイバック期間を短縮する方法はいくつかあります。CACを下げる（広告の効率化、自然流入の増加）、ARPUを上げる（価格改定、アップセル）、粗利益率を改善する（原価削減、効率化）などです。また、年間契約で前払いしてもらうことで、キャッシュフローを大幅に改善できます。

Rule of 40：成長と収益性のバランス

Rule of 40は、成長率と利益率の合計が40%以上であるべきという経験則です。たとえば、年間成長率60%で利益率-20%なら合計40%、年間成長率30%で利益率15%なら合計45%となります。

この指標が生まれた背景には、SaaS企業のジレンマがあります。高成長を追求すれば赤字になり、黒字化を急げば成長が鈍化する。どちらを優先すべきか、多くの経営者が悩みます。Rule of 40は、この両者のバランスを評価するシンプルで実用的な指標です。

アーリーステージでは、黒字化よりも成長を優先する判断が取られることもあります。たとえば高い成長率を維持できている場合、一定の赤字を許容しながら市場シェアの拡大を優先するケースがあります。ただし、資金調達環境や投資家の見方によって評価は大きく変わるため、Rule of 40はあくまで一つの目安として扱うべきです。上場を視野に入れる段階になると、年間成長率40%で利益率10%（合計50%）のような、よりバランスの取れた数字が求められる傾向があります。

Rule of 40を改善する方法は、ステージによって異なります。高成長だが赤字の企業は、ユニットエコノミクスの改善に集中すべきです。LTV/CAC比率を3倍以上に高め、ペイバック期間を短縮する。一方、黒字だが低成長の企業は、新たな成長要因を見つける必要があります。新市場への展開、新製品の開発、M&Aなどが選択肢になります。

LTV > 3 × CAC：黄金律の正しい使い方

LTV（顧客生涯価値）がCAC（顧客獲得コスト）の3倍以上であるべきという黄金律は、サブスクリプションビジネスの健全性を測る最も重要な指標です。なぜ3倍なのか、改めて整理しましょう。

まず、顧客獲得にかかったコストを回収する必要があります（1倍）。次に、その顧客をサポートし、サービスを提供するための運営コストをカバーする必要があります（もう1倍）。そして、ビジネスを成長させるための再投資資金と、投資家へのリターンを生み出す必要があります（さらに1倍）。合計で3倍です。

ここで重要なのは、LTVを計算する際に粗利益率を考慮することです。前回の記事では簡易計算として「LTV = 月額料金 ÷ チャーン率」を紹介しましたが、より実務的な計算式は次のようになります。

LTV = ARPU × 粗利益率 ÷ チャーン率

なぜ粗利益率を含めるかというと、売上のすべてが利益になるわけではないからです。サーバー代、決済手数料、カスタマーサポートのコスト、生成AIプロダクトであれば推論コストなど、顧客一人を維持するのにも原価がかかります。これを差し引かないと、LTVを過大評価してしまいます。

実際の計算例を見てみましょう。あるSaaSサービスのデータです。

この例では、LTV/CAC比が8倍と非常に高い数字です。これは効率的なビジネスで、積極的に投資して成長を加速すべき状態と言えます。粗利益率を考慮しない場合のLTVは500,000円になりますが、実態を反映した正確な数値は400,000円です。この差は、事業判断の精度に直結します。

多くのスタートアップは、初期段階でLTV/CAC比が1倍を下回ることも珍しくありません。これは必ずしも悪いことではなく、プロダクトマーケットフィット（PMF）を探している段階では、効率より学習を優先すべきだからです。重要なのは、PMFを見つけた後、速やかにLTV/CAC比を3倍以上に改善することです。

LTV/CAC比を改善する手段は複数あります。LTVを上げるには、チャーン率を下げる、ARPUを上げる、アップセル・クロスセルを増やすなどの方法があります。CACを下げるには、CVRを改善する、自然流入を増やす、紹介プログラムを強化するなどの方法があります。どの手段が最も効果的かは、ビジネスの状況によって異なりますが、一般的にはチャーン率の改善が最もインパクトが大きいとされます。

第6章のまとめ——AIプロダクトでは原価構造の可視化が鍵

生成AIプロダクトでは、従来のSaaS以上に原価構造の把握が重要です。推論コスト、外部API利用料、ログ保管、監査対応、カスタマーサクセス負荷が、粗利益率やペイバック期間に直接影響します。一人あたり月額1万円の売上があっても、ヘビーユーザーのAPIコストが月5,000円を超えてしまえば、粗利益率は50%を切り、ペイバック期間は倍近く伸びます。

したがって、単にユーザー数やARRを見るだけではなく、「どの顧客が、どの機能を、どれだけのコストで使っているか」を早い段階から可視化することが欠かせません。プランごとの利用上限設計、ヘビーユーザー向けの従量課金、モデルの使い分けによる原価最適化など、プロダクト設計と価格設計を一体で考える必要があります。Qualitegでも、AIプロダクトの原価可視化と価格設計の支援を行っています。

第7章：実践的な改善アプローチ

～データドリブンな最適化～

ファネル分析で改善ポイントを特定する

ファネル分析は、顧客が認知から購入、そして継続利用に至るまでの各段階を可視化し、どこで離脱しているかを特定する手法です。漏斗（ファネル）のように、段階が進むにつれて人数が減っていく様子を分析します。

典型的なSaaSのファネルを見てみましょう。まず、10,000人がウェブサイトを訪問したとします。そのうち3%（300人）が無料登録をします。登録した300人のうち、30%（90人）が無料トライアルを開始します。トライアルを開始した90人のうち、20%（18人）が有料プランに移行します。そして、有料化した18人のうち、90%（16人）が1年後も継続しています。

このファネルを見ると、最大のボトルネックは「無料登録→無料トライアル」の30%という転換率です。ここを改善することで、最も効率的に有料顧客を増やせます。たとえば、この転換率を30%から40%に改善できれば、有料顧客は18人から24人に、33%も増加します。

ファネル改善の具体的な施策を見てみましょう。「サイト訪問→無料登録」の転換率を上げるには、登録フォームの項目を減らす、ソーシャルログインを導入する、登録のメリットを明確に伝える、といった方法があります。たとえば、登録フォームの項目を10個から3個に減らすことで転換率が大きく改善した例も報告されています。

「無料登録→無料トライアル」の転換率を上げるには、オンボーディングメールの改善、製品ツアーの提供、カスタマーサクセスからの能動的な連絡などが効果的です。特に、登録後24時間以内のアクションが決定的に重要です。この時間内にユーザーが価値を感じなければ、二度とログインしない可能性が高いからです。

「無料トライアル→有料化」の転換率を上げるには、トライアル期間中の利用状況をモニタリングし、利用が少ないユーザーには追加サポートを提供する、トライアル終了前にリマインダーを送る、限定オファーを提示する、といった施策が有効です。

コホート分析で顧客の質を評価する

コホート分析は、同じ時期に獲得した顧客グループ（コホート）の行動を時系列で追跡する手法です。これにより、顧客の質の変化や、施策の効果を正確に測定できます。

たとえば、2024年1月に獲得した100人の顧客コホートを見てみましょう。2月には90人（90%）、3月には85人（85%）、4月には82人（82%）、5月には80人（80%）が残り、それ以降は80人前後で安定したとします。一方、2024年4月に獲得した100人のコホートは、5月に85人（85%）、6月に75人（75%）、7月に68人（68%）、8月に62人（62%）と、継続的に減少を続けたとします。

この分析から、1月コホートは質が高く、4月コホートは質が低いことが分かります。なぜ4月の顧客の質が低いのか、調査する必要があります。もしかしたら、4月に実施した大規模キャンペーンで、ターゲット外の顧客を獲得してしまったのかもしれません。あるいは、競合が新サービスをリリースし、比較検討で負けているのかもしれません。

コホート分析は、収益ベースでも行うべきです。顧客数は減っていても、残った顧客がアップグレードしていれば、収益は増加している可能性があります。理想的なのは、一部の顧客が解約しても、残った顧客のアップセルやクロスセルによって既存顧客群全体の収益が増える状態です。これは一般に「ネガティブチャーン」と呼ばれます。

コホート分析の結果を改善に活かす方法をいくつか紹介します。まず、優良コホートの特徴を分析し、そうした顧客を意図的に獲得する戦略を立てます。たとえば、特定の業界や企業規模の顧客の継続率が高いなら、そこにマーケティング投資を集中させます。

次に、質の低いコホートの改善です。すでに獲得してしまった顧客の性質は変えられませんが、オンボーディングやカスタマーサクセスを強化することで、継続率を改善できる可能性があります。特定のコホートに特化した再エンゲージメントキャンペーンも有効です。

最後に、季節性の把握です。多くのビジネスには季節性があります。たとえば、会計ソフトは確定申告の時期（2〜3月）に獲得した顧客の継続率が高い傾向があります。この知見を活かし、その時期にマーケティング投資を集中させる戦略が取れます。

A/Bテストによる継続的改善

A/Bテストは、2つ（またはそれ以上）のバージョンを同時に検証し、どちらがより良い結果を生むかを科学的に確かめる手法です。サブスクリプションビジネスでは、ウェブサイト、メール、プロダクト機能、価格など、あらゆる要素でA/Bテストを行う価値があります。

価格のA/Bテストは特に効果的です。たとえば、月額5,000円で提供していたサービスで、新規顧客を2グループに分け、Aグループには5,000円、Bグループには7,000円を提示したとします。結果、転換率はAグループが20%、Bグループが18%でした。一見Aグループのほうが良さそうですが、収益で計算すると、Aグループは5,000円×20%=1,000円、Bグループは7,000円×18%=1,260円となり、Bグループのほうが26%も収益が高いことが分かります。

なお、価格のA/Bテストは顧客体験や公平性への配慮が必要です。特にBtoBでは、同じ条件の顧客に異なる価格を提示すると信頼を損なう可能性があるため、プラン設計、訴求軸、割引条件など、検証対象を慎重に設計する必要があります。新規の検討段階でのランディングページ訴求や、時期をずらした段階的な価格改定の効果検証など、顧客に不公平感を与えない形で設計することが重要です。

オンボーディングのA/Bテストも効果的です。たとえば、製品ツアーを「スキップ可能」にするか「必須」にするかで検証した場合、必須にしたほうが、短期的には離脱率がやや上がる一方で、長期的な継続率が大きく向上する、といった結果が得られることがあります。最初は面倒でも、しっかり価値を理解してもらうことの重要性が示されるケースです。

メールの件名のA/Bテストは、最も簡単で効果的な施策の一つです。「期間限定！30%オフ」対「あなただけの特別オファー」、「新機能リリースのお知らせ」対「作業時間を50%削減する方法」など、異なるアプローチを検証します。開封率が数%改善するだけでも、その後のクリック率や成約にも連動して良い影響が出ます。

A/Bテストを行う際の注意点があります。まず、統計的な信頼性を確保することです。必要なサンプル数は、現在の転換率や検出したい改善幅によって変わります。少数のサンプルで判断すると、偶然の差を成果と誤認するリスクがあります。テスト期間も重要で、週末と平日で行動が異なる場合があるため、最低でも1〜2週間は継続して見るのが無難です。

第7章のまとめ——データドリブンは数字を眺めることではない

データドリブンな改善とは、数字を眺めることではありません。どの顧客に、どの価値が、どのタイミングで伝わっていないのかを特定し、プロダクト、営業、カスタマーサクセス、価格設計を同時に調整していくことです。

特にAIプロダクトでは、導入初期の期待値調整とオンボーディングが、その後の継続率に大きく影響します。生成AIは万能ではなく、得意・不得意があり、期待値を誤ったまま使い始めた顧客は、早期に「思ったほど使えない」と判断して離脱しがちです。ファネル分析やコホート分析で早期離脱の傾向を捉え、オンボーディングで正しい期待値とユースケースを丁寧に伝える設計が、結果としてLTVを大きく左右します。

Qualitegは自社サービスで得た知見をもとに、プロダクトの改善サイクルと並行して、指標設計・データ分析・カスタマーサクセスの運用を一体でご支援しています。数字を見る体制を作るだけでは不十分で、その数字から次の打ち手を導き、実際に実行まで落とし込める組織にすることが重要だと考えています。

次回予告

次回の第4回では、サブスクリプションビジネスでよくある失敗パターンと、その対策について詳しく解説します。フリーミアムの罠、過度な機能追加による複雑化、ダウンセルの軽視など、多くの企業が陥る落とし穴を、AIプロダクト特有の観点も交えながら掘り下げていきます。

それでは次回またお会いしましょう！

2026年時点での、過去からのNVIDIA GPU一覧を簡単にフィルタリングできるようにいたしました！GPU選定にお役立ていただけます！

関連ポスト

2025年 NVIDIA GPU 一発検索ツール(2025/8/5更新)

NVIDIA GPU 一覧検索 シリーズ すべて SM_100 (Blackwell) SM_90 (Hopper) SM_89 (Ada Lovelace) SM_86/SM_87 (Ampere) SM_75 (Turing) SM_70/SM_72 (Volta) SM_60/SM_61/SM_62 (Pascal) SM_50/SM_52/SM_53 (Maxwell) SM_35/SM_37 (Kepler) SM_20 (Fermi)

Qualiteg BlogQualiteg プロダクト開発部

NVIDIA GPU と Capability Level

NVIDIA GPU の Capability Level の一覧です。 推論エンジンがサポートする各種アクセラレーション機能は Capability Level により搭載されるハードウェアアクセラレータや専用機能が異なります。 データセンター/プロ向けGPU GeForce GPU Capability Level 世代名 - GeForce RTX 5090 120 Blackwell - GeForce RTX 5080 120 Blackwell - GeForce RTX 5070 120 Blackwell - GeForce RTX 5060 120 Blackwell NVIDIA B200 - 100 Blackwell NVIDIA B100 - 100

Qualiteg BlogQualiteg プロダクト開発部

PyTorchバージョンとNVIDIA GPU Compute Capability Level サポート

古いPyTorchコード資産を持っている会社は、昔のコードが最新のPyTorchで動かない！最新のGPUで動かない！ということに遭遇することが多いのでしょうか。 今回は、PyTorchバージョン、対応GPU Capability Level 、対応CUDAバージョンについてまとめてみます。 PyTorchがサポートするGPUの Compute Capability PyTorch バージョン サポートされる Compute Capability (SM) レベル 1.0.0 - 1.3.1 SM_35, SM_37, SM_50, SM_60, SM_61, SM_70 1.4.0 - 1.7.1 SM_37, SM_50,

Qualiteg BlogQualiteg プロダクト開発部

こんにちは！
Qualitegビジ開マーケティング部です！

2026年4月15日(水)から16日(木)までの2日間、幕張メッセで開催された「Startup JAPAN EXPO 2026」(主催:Eight / Sansan株式会社)に、
株式会社Qualitegとして出展してまいりました!

Startup JAPAN EXPO 2026 出展概要

今回の展示テーマは——

「依頼は並列に、思考は止めず。」

主力プロダクト「Bestllam®」に新搭載されたAIエージェント機能と、AIセキュリティソリューション「LLM-Audit™」の実演デモを、2日間にわたってお届けしました。

ブース番号は 16-16。展示ホール7・8の一角に、今回も気合いを入れて陣を構えました💪

プレスリリース

株式会社Qualiteg、「Startup JAPAN EXPO 2026」に出展

株式会社Qualitegのプレスリリース（2026年4月13日 10時00分）株式会社Qualiteg、「Startup JAPAN EXPO 2026」に出展

PR TIMES株式会社Qualiteg

開催前日【0日目】前夜祭「もう遅刻はしない」——前線基地、爆誕🏨

今回のレポート、まずはここから書かせてください。

前回のCEATEC 2025、覚えている方もいらっしゃるかもしれません。

そう、「最後に来て最後まで残る」 という新ジャンルを開拓してしまった、あの伝説の回です・・・。

深夜の幕張メッセ、誰もいない展示ホール、頭上に輝くオリオン座🌌——あの光景、美しかったけれど、二度と見たくはありません😇

そこで今回、私たちはある決意をしました。

「今度こそ、遅刻寝坊を撲滅する（💦）」

その名のもとに、前日入りを敢行。

幕張メッセ直結＆徒歩圏のアパホテル＆リゾート〈東京ベイ幕張〉に、"前線基地"　を設営することにしたのです

前線基地からは、眼科に幕張メッセがバッチリ見えます（ちなみに左上はZOZOマリンスタジアム🥎です、試合してました＾＾）

さて、現地での対応は、マーケチームの元気メンバー3名体制。エンジニアも帯同し、何があってもその場で技術対応ができる布陣です。

「これで完璧だろう」

・・・と、このときの私たちは思っていました

実は、デモには"舞台装置"がありました

前日入りしたその夜、前線基地の一室で、改めて2日間分のデモのリハーサルを回していました。

ここで少しだけ、デモの裏側の話をさせてください。

Bestllam® AIエージェントのデモで、私たちがどうしても見せたかったのが——

「日本企業の業務現場に、本当に溶け込んでいる感じ」

でした。

「AIエージェントがWeb検索して、要約してくれます」——それだけなら、そんなに珍しくない時代です。

私たちがお見せしたかったのは、もう一段奥、

"基幹システムや売上管理DBと連携して、業務の中で働くエージェント"

そこで、今回のデモのために、エンジニアチームが
企業の基幹システムや売上管理DBを模した"模擬MCPサーバー"
を自作していたのです🛠️

• 架空の顧客マスター(数千件)
• 架空の売上トランザクション
• 架空の契約情報、社外秘の案件名
• 架空の勤怠データ
• 架空の契約書・議事録・顧客対応メモなどの業務文書

これらが、本物の基幹システムっぽい挙動でレスポンスを返す——そんな舞台装置を、ブースの裏で動かす予定でした。

これがあるから、

• 1日目のBestllamデモでは、エージェントが「先月の売上トップ5を部署別に集計して、来月の見込みと並べてPowerPointでまとめて」みたいな指示で、模擬DBを叩いて結果を返せる
• 2日目のLLM-Auditデモでは、模擬基幹システムから引いてきた"いかにも機密情報"なテキストを、そのままLLMに送ろうとしたときにリアルタイムで検出・マスキング・仮名化できる

——という、2日間を貫く一本のストーリーが成立するわけです。

ところが、その模擬MCPが、夜に入って不機嫌になった

前線基地でリハーサルをしていたエンジニアが、ぽつり。

「・・・あれ、これ、挙動ブレてない?」

症状は、地味で嫌な感じのやつでした。

• 複数サブエージェントが並列でアクセスしたときに、レスポンス順がたまにバラつく
• 特定の問い合わせパターンで、返すデータのスキーマが微妙に揺れる
• 結果、エージェントが"念のためリトライ"を挟んで、体感で数秒モタつく

プロダクト本体(Bestllam / LLM-Audit)は、完璧に動いています。本社のスタジオ環境では、何度も動作確認済みです。

不機嫌なのは、私たちが今回のデモのために自作した、模擬基幹システムMCPのほうでした。

でも、来場者の方から見たら、そんな裏側は関係ない。

「エージェントが、なんか待たされてる」

——そう見えた瞬間に、「依頼は並列に、思考は止めず」というメッセージの説得力が、コンマ数秒単位で目減りしていく。

展示会のデモは、コンマ数秒の違和感を、許さない。

「じゃあ、やるか」——赤飯おにぎり、魂の燃料🍙

前線基地(アパホテル幕張)の一室に、緊急の作戦司令室が爆誕しました🔧

• 模擬MCPの並列処理ロックの見直し
• レスポンススキーマの固定化
• 想定される指示パターンの洗い出しと、それに対する応答の事前リハーサル

・・・気づけば、お腹がペコペコ。

ホテル２Fのローソンにダッシュして、赤飯おにぎりを大量に買い込んできました🍙

「なんで赤飯?」 と聞かれたら、理由はありません。なんとなく目に入った瞬間、"験担ぎ" のスイッチが入ってしまったのです。

「明日、初陣なので」

そんな謎の理由で、深夜の前線基地で赤飯おにぎりをばくばく食べながら、作業を続けました。

(ちなみに赤飯のカロリーは全て"魂の燃料"という名目で処理されました。栄養学的にはどうなんでしょう😇)

おにぎりを頬張りながら、模擬MCPを叩き、ログを見て、また直す。

"舞台装置"が完璧に動かないと、主役(Bestllam / LLM-Audit)の本当の魅力は伝わらない——そんな気持ちで、メンバー全員(リモート参加のエンジニアメンバーも）が手を動かし続けました。

気づいたら、明け方。

ふとカーテンを開けると——

zozoマリンスタジアムの奥、白みはじめた東京湾の向こうに、うっすらと塔のようなものが浮かんでいました、

東京スカイツリー、でした！

なんだか神々しい！

ちょっと湿った朝の空気。

眼下に広がる夜明け特有の静かな佇まいが、これから始まる戦いの舞台に見えました。

模擬MCPが安定して動き出したとき、エンジニアは満足そうに一言。

「よし、舞台、整ったぞ。初日、やれる気がする」

謎の確信を得て、私たちは1日目の戦場へ向かいました。

【1日目】Bestllam AIエージェント——"専任チーム"が動き出す瞬間

午前中はやや曇っていた空も、ブースがオープンする頃には、気持ちよく晴れてきました🌞

天気と同じく、1日目のブースも、気持ちよく走り出しました。

初日のメインは、Bestllam® の新機能 AIエージェント。

従来のAIチャットの体験って、「人間がAIの返答を待ってから次を考える」——この往復構造に縛られていますよね。AIを使うほどに思考が寸断されていく、あの感じ。

Bestllamの新しいAIエージェントは、これをひっくり返します。

指示した瞬間、自分だけの専任チームが動き出す。

統括エージェントが司令塔となり、複数のサブエージェントが並列でリサーチ、資料作成、データ整理、メール下書きなどを非同期に進めていく。ユーザーは返答完了を待たずに、次の指示をどんどん重ねていける。

• 「先月の売上トップ5を部署別に集計して、来月の見込みと並べて」
• 「同時並行で、主要顧客への訪問スケジュールもドラフトしておいて」
• 「ついでに、その訪問内容を部長向けの報告書フォーマットで一枚にまとめて」

・・・と、指示をどんどん重ねていくことがもうできるようになっています

こういったAIエージェント機能は、特に経営層や事業責任者の方々からの反応が熱く、

「社内でAI使ってるけど、結局1人で作業してる感覚と変わらなかった。これは"チーム"ですね」

という、まさに私たちが狙っていたど真ん中のコメントをいただけたときは、開発チームに代わってガッツポーズしてしまいました👊

"基幹システムと繋がって働いているAIエージェント" の感触が、ちゃんと伝わった瞬間でした

おかげさまで1日目のブースは、熱気につつまれました。

連日の準備で少し疲れていたメンバーも、来場者の皆様の反応にエネルギーをもらい、閉幕のアナウンスが流れるまでデモ回し続けました。

Qualitegをさがせ！

さて、会場全体もたいへんな熱気につつまれていました。

１日目の会場はこんなかんじです。すごいですね！

さてここで、問題です。

当社 ㈱Qualitegのブースはどこでしょう？

ヒント：クリエイティビティを深化させようとするエネルギーが最も解き放たれているところ

AIチャット を入れただけでは真の業務改善には程遠い

ここで当社の提供するコンサルティングについても、触れさせてください。

当イベントでも、ブースを来場・ご予約いただいたお客様の課題として、

・生成AIを導入したがチャットだけでは業務効率化にはつながらない
・PoCまではいくが、全社展開となると難しい

といった課題や、

・生成AIを使った情報システム開発の刷新をしたいが、どこから手を付けたらいいのか、どのような開発プロセスの変革が必要なのか、全体像が整理できてない

といった課題の声をいただきました。

まさに、ここは当社の得意とする部分なのですが、
単にツールやSaaSを開発・提供して「はい、つかってください」だけで本当の変革を実現することは難しいです。

当社は外資系コンサルティングファームで長年経験を積んだコンサルタントチームとAIの専門家チームがタッグを組んで、本当の変革につながるAI業務改善をご支援しております。

今回のイベントでは、そうした課題意識のあるお客様にもご来場いただき、早速、イベントご来場者様向けの無料のスポットコンサルの打診をいただきました。このたび、イベント出展記念として無料のスポットコンサル枠を増やしておりますので、ご興味のある方は こちら までお問い合わせくださいませ。

先ほどの答え、Qualiteg ここです

さて、さきほどの Qualitegを探せ はいかがでしたでしょうか？

簡単でしたか？

答えは以下となります。

このようなたくさんのブースの中から当社にご来訪、ご面談予約をいれていただきました、皆様、あらためて御礼もうしあげます。

【1日目夜】"機密文書エンドポイント"、再び荒ぶる🌙

さて、1日目を終えて前線基地に戻るエレベーターの中で、展示担当メンバーは達成感でいっぱいでした。

「明日も頑張るぞ〜」

そう、明日・2日目の主役は、LLM-Audit™です

LLMに機密情報が送られる前段で、リアルタイムに検出・ブロック・マスキング・仮名化する仕組みです。たとえば、

「田中太郎さん(090-1234-5678)から問い合わせがありました」

を、LLMに送ろうとした瞬間に、

「[顧客A]さん([電話番号])から問い合わせがありました」

へと一瞬(数ms)で変換してみせる、あの "セキュリティチェックの存在を感じさせない気持ちよさ" つまり、ちゃんとセキュアだけど、AIを使ってる時にセキュリティチェックを感じさせないということは当プロダクトのUXの命です。

そして、このデモを本当にリアルに見せるためには、
（ホントの機密情報はだせませんが）"いかにも機密情報"な業務文書を、
模擬基幹システムMCPから引いてくる必要があります。

軽いエンドポイントはOK、でも"長文文書"は未検証だった

0日目夜に直した模擬MCPは、軽いデータを返す系のエンドポイント——売上集計、スケジュール、顧客ID・・・そういう構造化データは、1日目に何とか乗り切りました。

しかし、契約書・議事録・顧客対応メモ・稟議書といった長文の業務文書を返すエンドポイントは、1日目には一度も叩いていなかったのです。

2日目のリハーサルとして、その機密文書エンドポイントを叩いてみると——

「・・・あ」

エンジニアの表情が、また曇りました

症状は、これまた地味で、しかし致命的なやつでした

• 長文テキストにPIIが入っていない（デモの見せ場がない）場合がある
• その結果、LLM-Audit側の検出エンジンが、引っかかるときと、すり抜けちゃう瞬間がときどき発生
• 用意していた機密文書のバリエーションが圧倒的に足りない——来場者の方に何度触っていただいても、同じ議事録と同じ契約書が出てきてしまう

LLM-Audit本体の検出エンジン(PII-Fi™)は、完璧に動いています。

不機嫌なのは、またしても模擬基幹システムMCPのほう。しかも今度は、"機密情報を引いてくる"という一番肝心なところで躓いた形です。

「昨日の今日かよ・・・!!」

思わず天を仰ぎました🙄

でも、この問題を放置して2日目を迎えるわけにはいきません。

LLM-Auditのデモは、"あ、こんな自然な文章の中からも見つけ出すんだ!" という驚きが命。でもまったくＰＩＩが入っていない文章だと、さすがにみつけだせないので、でも、ランダム生成のいかにも機械的な文章では、検出されて当然すぎて面白くないのです。

実務で本当に飛び交っているような、自然な日本語の業務文書——それを、比較的大量に用意する必要がありました。

「じゃあ、やるか」——2夜連続

前線基地の作戦司令室、2夜連続稼働が決定しました

昨夜は模擬MCPの骨格を直し、今夜は模擬MCPから引き出すコンテンツを仕上げる。

昨夜は赤飯でしたが、今夜は——

「ピザ、食べよう」

深夜までやっているアパホテル内のお店(MOMOCAFEさん)にダッシュ、ピザをテイクアウトで買ってきました🍕

「ピザ、うますぎる・・・」

昨夜の赤飯おにぎりと並ぶ、深夜の"魂の燃料"。深夜のピザのカロリーは全て(以下略)。

ピザを頬張りながら、作業内容はこんな感じでした

• 契約書・議事録・顧客対応メモ・稟議書——架空のパターンを、ひたすら書き起こす(マーケ担当で創作します) まぁ、BestllamでLLM使って作ることもできますが、それじゃあまりにもつまらない。
• 文書の中に「田中太郎様」「株式会社〇〇商事」「090-1234-5678」「第3四半期決裁案件 — 社外秘」といったリアルな埋め込みを自然に混ぜ込む
• そして、わざと表記揺れを入れ込む。表記ゆれに強いので。マーケ担当はPII処理の内部ロジックを知らないので、検出しやすい文章にならないのもいいんです。
• 最後に、LLM-Audit側で検出〜仮名化〜表示までの体感速度を、もう一段気持ちよく見えるように整える

ちなみに、実はデモのことを考えてこうやって展示会で準備すると、普段のオフィスでの開発より進んだりするんです。だから実際には、体験デモにこぎつけないときも、こうやってリアルを想像してデモすることって本当に重要だと、１０回以上展示会に本気出展してみて、きづきました。

深夜4時——「あれ、これURL、まちがってない?」

時刻は、深夜4時を回ったころ。

前線基地の一室。模擬MCPと架空議事録の格闘が、ようやくゴールが見えてきた頃でした。

コードを書いていたエンジニアが、机の端に置かれていたブース配布用のチラシを、何の気なしに手に取りました。

「・・・あれ、これURL、まちがってない?」

部屋の空気が、ピシッと凍りました🧊

「え」 「え?」 「ええええええ!?」

メンバーが机に駆け寄ります。

確認してみると——2日目にフィーチャーするLLM-Audit™の紹介QRコードと遷移先URLに、不備があったのです。

1日目はBestllamの展示が中心だったので、誰も気づかなかった。でも2日目の主役はLLM-Audit。このまま配ったら、来場者の皆様を間違ったページに案内してしまう。

展示会のチラシ・ポスターは、名刺代わりの顔です。しかも、LLM-Audit™の興味を持ってくださった方をお連れする先——つまり、一番届けたい情報への入り口が間違っているということ。

「これは、直さないと開場には立てない」

全員の意見は一致しました。

「アクセアさん、お願いします・・・!!」

全速力でポスターとチラシのデータを修正。正しいURL、正しいQRコード、正しい遷移先。深夜4時の前線基地で、もう一度ディレクターチェック、プルーフリーディング、最終確認。

そして頼みの綱は幕張メッセ近くにあるアクセア 海浜幕張店さま。

開店は、朝8時。

「いまのうちにWeb入稿して、アクセア様開店の8時ジャストできづいてくだされば、9時には刷り上がる・・・かもしれない」 「開場は10時・・・ギリッギリ」 「祈ろう」

データを入稿フォームにセットし、送信ボタンに指を載せたまま、みんなで本気の祈りを捧げました🙏

「アクセアさん、お願いします・・・!!」

深夜対応明け、そして快晴

そこまでやって、ようやく、前線基地の作戦司令室は店じまいとなりました。

• 模擬MCPの機密文書エンドポイント→修正完了✅
• 架空業務文書のバリエーション→書き起こし完了✅
• ポスター・チラシのURL修正→入稿完了✅

目の下にクマを貯金しながら、それでも不思議と充実感がありました。

充実感は、きっと、やらされてるんじゃなくて、やりたくてやってるからですね

そして、気づいたら、
また朝じゃん。

カーテンを開けると——

おおー、富士山🗻が見えるではありませんか。

前日の曇天とは打って変わって、東京湾の向こうからうっすらした富士山、

幕張メッセの屋根が、光を反射してキラキラ光ってる

「よし、2日目、やれる」

2夜連続の深夜対応明けですが、快晴の空が、なんだか背中を押してくれる気がしました♪

【2日目】LLM-Auditデモ——"しみじみ"聞こえてきたAIセキュリティの本音

2日目は、LLM-Audit™ が主役。

その前に——アクセアさんからの朝イチの電話📞

朝、快晴の空の下を幕張メッセに向かって歩いていたメンバーの携帯が、震えました。

「先ほどいただいたデータ、急いで刷っておきました。いつでも取りに来てください!」

・・・一瞬、立ち止まりました。

「ほ、本当に・・・!?」

深夜に祈りながら入稿したデータが、開店と同時に印刷されて、もう刷り上がっている。

こちらの「なんとかギリギリで間に合わせたい」という都合を、電話の向こうの担当者さまが完全に汲み取って、全力で作業してくださったのが伝わってきました。

電車移動組メンバーに駅前にあるアクセアさんにポスターをとりにいってもらい、無事ことなきをえました

アクセア 海浜幕張店のスタッフの皆様——本当に、本当にありがとうございました🙇‍♂️🙇‍♀️

あの突然の深夜入稿。事情の説明も最小限だったはずなのに、こちらの意図を読んで、朝イチで仕上げて、朝イチで電話をくださる。これこそ、プロの心意気だと、感動しました。

修正したてのチラシ・ポスターを抱えて、私たちは2日目のブースへと滑り込みました。間に合った。

いざ、LLM-Audit出展

刷り立てホヤホヤの正しいチラシ・ポスター。準備は、文字通り最後の一瞬まで整えました🙏(前夜と前々夜の自分たち、そしてアクセアさん、本当にありがとうございました)

LLM-Audit(PII-FI)では

• 「電話番号や住所が入ったテキスト」 → 一瞬でマスキング
• 「顧客名+契約金額」 → 仮名化して文脈を保ったままLLMへ
• 「社外秘のキーワード」 → 事前学習済みのPII-Fi™が即検知してブロック
• 「議事録の中に自然に混ざった、敬称付きの人名と案件名」 → 日本語特有の表記ゆれも含めて検出

を一瞬(数ms）で実行することができます

"しみじみとしたお悩み"、聞こえてきました

そして今回、何より印象的だったのは、来場いただいた方々から聞こえてきた"しみじみとしたお悩み" でした。

「うちの社員、もう勝手にChatGPTに会議の議事録投げちゃってるんですよ・・・」 「契約書の内容をAIに要約させてるのが発覚して、法務が青ざめてて」 「シャドーAI、どうやって止めたらいいんでしょうか」

・・・ここ、少し真面目に書かせてください。

私たちがLLM-Auditを作り始めたとき、最初に想定していたのは「悪意ある攻撃者からLLMを守る」というユースケースでした。
つまり自社が作ったAIに対する攻撃(ジェイルブレイク)や不適切出力、春市ネーションの検出といった分野です。

でも、開発を続ける中で、

本当に深刻なのは、
悪意なき日常業務からの情報漏洩

のほうが「待った無し」だ、という確信に変わっていきました。

（もちろんジェイルブレイクやプロンプトインジェクションといった課題に対してもLLM-Auditは活躍しますし、当社のAIレッドチームが日夜腕を磨いています💪)

今回、まさにその現場のリアルな声を、たくさん聞かせていただきました。

• うっかりAIに機密情報を送ってしまう
• 便利だからと社員が個人契約のAIを使い始める(シャドーAI)
• 気づいたときには、情報がどこに流れたか追跡できない

これらは、LLM-Auditがまさにカバーしたい領域そのものです。

「あ、私たちの方向性、間違ってなかったんだ」

ブースの中で、チームが静かに目を合わせて頷いた瞬間がありました🥹

まさにその"最後の一歩"を支えるために存在しているのだと、改めて腹落ちした時間でした。

【2日目夕方】前線基地から見た、あの夕日🌇

さてさて、
長かった2日間の展示も、クロージングの時間。

ブースを片付け、荷物をまとめて、前線基地に戻ってきたのは夕方でした。

エレベーターで高層階まで上がり、ふと窓の外を見ると——

最高に、きれいでした。

東京湾の向こうに沈んでいく夕日。

オレンジとマリンブルーが溶け合う瞬間。

「2日間、ほんとに走り切ったな」

「ピザうまかったな」

「アクセアさん、本当に救ってくれたな」

「あの人、めっちゃ笑ってくれたな」

しばらく無言で夕日を眺めていました。

展示会というのは、準備から本番、撤収まで含めて、本当に"ドラマ" だなと思います。

赤飯おにぎりを頬張った0日目の夜も、1日目の曇り空も、熱気も、ピザを頬張った1日目の深夜も、"架空の議事録"を書き続けた作業も、深夜のポスター事件も、アクセアさんからの朝イチの電話も、快晴の朝の空も、お客様の"しみじみ"した一言も、ホリエモン講演の熱気も、全部ひっくるめての2日間。

この夕日は、走り抜いた人にだけ見せてくれるご褒美だったのかもしれません🥹

まとめ 〜未来への手応え〜

今回のStartup JAPAN EXPO 2026は、2日間という短い期間でしたが、Qualitegにとって大きな意味を持つ2日間になりました。

Bestllam® AIエージェントへの想像以上の反響

「依頼は並列に、思考は止めず」というコンセプトは、来場者の方々の体感として深く届いたという手応えがありました。

特に経営層・事業責任者の方々からの熱い反応は、私たちが目指している "働くAI" の方向性が、確かに日本のビジネス現場に求められているものだという確信を与えてくれました。

LLM-Audit™へのリアルな期待

シャドーAI、うっかり情報漏洩——これらは、もはや"将来の懸念"ではなく、今、目の前で起きている課題です。来場者の方々から聞こえてきた"しみじみとした声"は、日本企業のAI活用がまさに次のフェーズ——ガバナンスとスピードの両立へと進んでいることを示していました。

LLM-Audit™は、その"最後の砦"として機能するプロダクト。今回のデモを通じて、「ああ、まさにコレが欲しかった」 と言っていただけたことが、何よりの励みになりました。

そして、チームで走り抜いた手応え

今回のStartup JAPAN EXPOは、マーケティングチームとエンジニアチームの総力戦でした。

会場で笑顔で対応する裏側には、前夜と前々夜の仕込み、夜中の改善、朝方の最終確認、無数の準備がありました。

それでも、「最後に来て最後まで残る」 のジンクスは、今回ちゃんと破りました!✨

次回はきっと、「最初に来て最初に帰る」 の常識ジャンルにも到達してみせます(できるのか?)。

関係者の皆様、そしてお越しくださった皆様へ

主催のEight(Sansan株式会社)様、会場運営スタッフの皆様、同日開催Climbers運営の皆様、そしてブース番号 16-16 にお立ち寄りいただいたすべての来場者の皆様——

本当に、本当にありがとうございました🙇‍♂️🙇‍♀️

そして、アクセア 海浜幕張店のスタッフの皆様——

開店前の突然の入稿、無理筋のスケジュール、それでも朝イチで刷り上げて、朝イチでお電話をくださったあのプロフェッショナルな対応に、心から感謝申し上げます。お陰様で、2日目の開場に間に合いました。

ちなみに１日目のポスターもアクセア大手町店さまが、急ぎ対応したいただいたりと、アクセアさんなくして、今回の展示は完成しませんでした🙏

「Bestllamのエージェント、うちの部署で試してみたい」 「LLM-Auditの話、情シスに共有したい」 「Qualitegのコンサル、まず1回相談させて」

——こんなお声をたくさん頂戴しました。いただいたご縁を、一つひとつ、ちゃんと次につなげていきます。

そして、遠方からブースを目指して駆けつけてくださった皆様、SNSで応援してくださった皆様、このレポートを最後まで読んでくださったあなたへ。

Qualitegは、これからも「世界中の人々のクリエイティビティを深化させる」という理念のもと、日本のビジネス現場に本当に溶け込むAIを作り続けてまいります。

次回のイベントでも、皆様と直接お会いできることを、チーム一同楽しみにしております!

最後までお読みいただき、誠にありがとうございました✨

また、お会いしましょう〜😊

2026年4月13日 プレスリリース

株式会社Qualiteg、「Startup JAPAN EXPO 2026」に出展

株式会社Qualitegのプレスリリース（2026年4月13日 10時00分）株式会社Qualiteg、「Startup JAPAN EXPO 2026」に出展

PR TIMES株式会社Qualiteg

「Bestllam®」に、AIエージェント機能を搭載

― 依頼は並列に、思考は止めず。日本企業の業務システムに溶け込む"働くAI"へ ― 生成AI導入・AIエージェント・業務自動化・コンサルティング

株式会社Qualiteg（本社：東京都千代田区、代表取締役：三澤智則）は、2026年4月15日(水)から16日(木)まで幕張メッセで開催される「Startup JAPAN EXPO 2026」（ブース番号：16-16）に出展いたします。

この度、主力プロダクト「Bestllam®」にAIエージェント機能を新搭載しました。依頼した瞬間に専任チームが動き出し、複数業務を並列自動処理する新UXを、本展示会にてデモ体験いただけます。

あわせて、AIを活用したいがガバナンスへの不安から全社導入に踏み切れていない企業、またはツールを導入したものの業務効率化につながっていない企業向けに、AI業務改善コンサルティングの受付も行います。

■「Startup JAPAN EXPO 2026」開催概要

■ 主な展示内容

展示① 統合AIプラットフォーム「Bestllam®」実演デモ

特長①【新機能】AIエージェント｜指示した瞬間、自分だけの専任チームが動き出す。思考を止めずに、仕事が終わっている。

生成AIの業務活用は急速に広がる一方、AIチャットの体験は依然として「人間がAIの返答を待ってから次を考える」往復構造に縛られています。AIを使うほどに思考が寸断されるという、逆説的な課題です。

もし、思いついた瞬間にどんどん指示を投げるだけで、気づいたときには仕事が終わっていたら——Bestllamはその体験を実現します。指示した瞬間、自分だけの専任チームが出来上がります。各サブエージェントが並列で仕事を進め、統括エージェントが成果をまとめてあなたに届けます。

まるで、優秀なチームを持つ経営者になったような感覚で、仕事が進んでいきます。AIの返答完了を待たず、返答中であっても次の指示を重ねられる構造により、思考を中断させない業務進行が可能になります。

Bestllam AIエージェントが提供する3つの価値

1. 託せる｜頼んでおけば、仕事は終わっている ユーザーは依頼を投げるだけで、サブエージェント群が裏で非同期に業務を進行。リサーチ、資料作成、データ整理、メール下書き、社内ナレッジ検索など、複数タスクが並行で完了します。

2. 止めない｜返答を待たずに、次の依頼を投げていい 統括エージェントがリクエストを一手に引き受け、背後の複数サブエージェントが並列に処理します。ユーザーは思いついた順に指示を重ねることができ、思考の流れを断ち切られません。Bestllamがこれまで培ってきた「複数LLMの同時稼働」の並列処理アーキテクチャを、エージェント実行基盤へと拡張したものです。

3. 守れる｜LLM-Audit™による情報漏洩の検出・マスキング 自律的に動くAIに機密情報や個人情報が紛れ込むリスクを、Qualiteg独自の「LLM-Audit™」が入出力双方で検出・マスキング。さらに官公庁・自治体向けには、データを国外に出さない「クロスボーダー保護」オプションを提供します。

• 単一窓口への依頼で複雑な調査・業務を自動完結。LLM-Audit™連携で全操作ログ・監査対応
• 途中変更OK。追加指示・方向転換にもリアルタイムで対応し、全体を整合させながら進行
• 日本企業固有のシステム制約（勤怠・基幹系など）に対応した独自MCPコネクタ開発済み

👉 詳細を見る

特長② Bestllamの基盤｜20種類以上のAIが使えるから、シャドーAIが消え、エージェントが強くなる。

いま、「シャドーAI」が企業のリスクとして注目を集めています。使いたいAIが社内で使えない。申請が通る頃には新モデルが出ている。部署ごとに最適なAIは違うのに、契約できるのは1種類だけ——こうした状況の中で、社員が個人でAIを契約して業務に使い始めてしまうケースが、各企業で報告されています。

Bestllam®なら、GPT・Claude・Gemini・Grok・Qwen・DeepSeekなど20種類以上のLLMを契約一本で使い分けられます。最新のモデルや部署ごとに異なるニーズに社内で応えられる体制を整えることで、シャドーAIの発生リスクを抑える一助となります。

そしてこの複数LLMが並列稼働できる基盤は、エージェント機能の原動力であると同時に、従来のAIチャットとしての価値もさらに引き出します。複数のLLMに同じ質問を同時に投げて回答を比較する——モデルごとの得手不得手を踏まえた意思決定や、回答の整合性チェックによる信頼性向上が、日々の業務の中で自然に行えます。エージェントには最適なモデルを自動選択させ、最大6モデルの同時稼働で精度を高める。チャットでは複数モデルの回答を横並びで検討する。同じ基盤が、両方のユースケースを支えます。

さらにエージェントが自律的に動く中での情報漏洩リスクには、当社のセキュリティプロダクト「LLM-Audit™」がガーディアンエージェントとして対応します※。LLMへ情報が送られる前段で機密情報・個人情報を検出し、ブロック・マスキング・仮名化を行うことで、外部LLMへの情報漏洩を防ぎます。その検出エンジンとして動作するのが、自社開発の基盤技術「PII-Fi™」です。一般的な個人情報だけでなく、企業ごとの「自社にとっての機密情報」を事前に学習させることで、その企業の文脈に沿った高精度な検出が可能になります。

• 20種類以上のLLMを契約一本で。エージェントにもチャットにも使い分け可能、シャドーAIリスクの抑制にも寄与
• 複数LLM同時質問：同じ質問を複数モデルへ並列に投げ、回答を比較検討できる
• LLM-Audit™：機密情報・個人情報の検出、ブロック、マスキング、仮名化により外部LLMへの漏洩を防止※
• PII-Fi™（基盤技術）：一般PIIに加え、企業独自の機密情報を事前学習可能。高速・高精度な検出エンジン

※LLM-Audit™はオプション機能です。

👉 詳細を見る

特長③ AIコンテンツ生成｜画像・文書・動画まで、テキスト一つで作れる。

資料の挿絵を探す、報告書のフォーマットを整える、プレゼン資料をつくる ——こうした制作業務に、これまでどれだけの時間を費やしてきたでしょうか。Bestllamはテキスト一つから、多様なコンテンツをその場で生成します。

まずAI画像生成はBestllam®の基本機能として標準搭載。「コーポレートカラーで製品の挿絵を作って」と指示するだけで、ブランドに合った画像を即時生成します。Word・Excel・PowerPointの文書・資料もAIが自動生成し、定型業務や報告書作成を大幅に効率化します。

• AI画像生成：商品画像・資料挿絵・SNS素材をテキスト一つで即時制作
• Word・Excel・PowerPoint文書をAIが自動生成。定型業務・報告書作成を大幅に効率化
• AIアバター動画生成：オプションにより、AIアバター動画生成サービス「MotionVox®」と連携可能。顔出し・声出し不要で動画コンテンツを制作。27言語対応

Bestllamの立ち位置 ― 日本の法人現場に届くAIエージェント

エージェント型UXは、すでにグローバルで主流となりつつある潮流です。そのうえでBestllamが目指すのは、日本企業の業務現場に本当に溶け込むかたち——基幹システムや社内ナレッジベースとの接続（MCP他）はもちろん、人間の同僚と共同作業をしているかのような自然なやり取り、迷わず使える操作感、任せて安心できる挙動。相手の意図を先回りして汲み取る、日本ならではの"おもてなし"の感覚を、プロダクトの隅々にまで織り込んでいます。

そして、そのおもてなしはプロダクトの中だけに留まりません。当社のコンサルティングチームが、PoCから運用設計、現場トレーニング、業務プロセス再設計までを一貫して伴走。プロダクトと人の両輪で、AIが現場で本当にワークするまでの「最後の一歩」を、責任を持ってご一緒します。

展示② AI業務改善コンサルティング（招待制から一般受付へ）

次のようなお悩みをお持ちの企業さまに向けて、実務に根ざした伴走型コンサルティングを提供します。

• 「生成AIを導入したが、チャットするだけで業務効率化につながっていない」
• 「PoCで終わってしまい、全社展開に踏み切れていない」
• 「ガバナンスや情報漏洩リスクへの不安から、全社導入を決断できていない」

PoCから運用設計、現場トレーニング、業務プロセス再設計まで一気通貫で支援。最先端に精通したAIエンジニアと大企業の業務改革で長年にわたって支援経験のある経験豊富な戦略コンサルタントが一体となったチームが、AIを"入れただけ"で終わらせない現場主義の伴走を提供します。

👉 詳細を見る

■ ブース来場特典

🎁 ブース来場・4月中お申し込み限定特典

• AI業務改善コンサルティング 初回契約総額から 20%オフ
• Bestllam® 初期費用 20%オフ

※ブース16-16にてお申し込み受付。4月30日(木)までのご契約が対象。

■ 株式会社Qualitegについて

株式会社Qualitegは、2023年7月に設立されたAIカンパニーです。「世界中の人々のクリエイティビティを深化させる」という経営理念のもと、最先端のAI技術を通じて、技術的障壁や言語の壁、身体的制約を取り払い、すべての人が持つ創造的な潜在能力を解放することを目指しています。

当社は、人々の創造力を増幅し、これまで想像もできなかった新たな表現と価値を生み出す世界の実現に取り組んでいます。AGIからASI、そしてデジタルヒューマンへと至る技術革新は、AIと人間の自然な協働を可能にし、誰もが直感的にAIを活用して自らの創造性を飛躍的に深化させる未来を約束します。技術格差による分断のない、すべての人がその創造性を解放できる社会を創造します。

自社サービス

• ビジネスを加速させる、統合AIプラットフォーム Bestllam®
• テキスト・音声等からリアルなAIアバター動画を生成 MotionVox®
• LLMの入出力を監査し、情報漏洩リスクを防御 LLM-Audit™
• 個人情報・機密情報を高速・高精度に検出・マスキング PII-Fi™ API
• オープンソースLLMでチャットボット・推論環境構築 ChatStream®
• AI・DX・戦略・新規事業・オープンイノベーション コンサルティング

■ 本件に関するお問い合わせ

株式会社Qualiteg Email：startupjapan2026@qualiteg.com

👉 お問い合わせ・デモのご依頼

Project Glasswingが映し出す、防御側のパラダイム転換

すごいモデルが出た、らしい

2026年4月7日、AnthropicがClaude Mythos Previewという新しいAIモデルを発表しました。(Anthropic公式発表 / Anthropic技術解説)

Anthropicは、ChatGPTで知られるOpenAIと並ぶ米国の大手AI企業のひとつで、Claudeシリーズと呼ばれる生成AIモデルを開発しています。

普段なら、新モデル発表は「より速く、より賢くなりました」というアップデートの話で、誰でも触れるようになるのが通例です。

ところが今回はだいぶ様子が違いました。

一般公開はされません。

アクセスできるのは選ばれた一部のパートナーだけ。

同時に立ち上げられた業界横断プロジェクト「Project Glasswing」の枠組みの中で、防御目的に絞って提供される、という発表でした。

ただ、この話を「危険なAIが出た」の一言で受け止めると、もっと重要なところを取り逃してしまいます。

少し腰を据えて見ていきましょう！

どのくらい「とんでもない」のか

まず性能面の数字から見ていきます。AIモデルの能力は、業界共通のベンチマーク(試験のようなもの)で比較されるのが通例で、今回もいくつかの代表的な指標が発表されています。

• SWE-bench Verified で93.9%(Anthropicの現行最強モデルClaude Opus 4.6は80.8%)。
  これはGitHub上の実際のソフトウェアバグをAIに修正させる試験で、いま業界がもっとも注目している実務系の指標です。
  
• Terminal-Bench 2.0 で82.0%(同65.4%)。
  AIがターミナル(コマンドライン)上で複数ステップの作業を自律的にこなせるかを測る試験です。
  
• GPQA Diamond で94.6%(同91.3%)。物理・化学・生物の博士課程レベルの問題を解かせる試験で、関連分野のPhD取得者でも65〜70%程度しか取れないと言われています。

数字の細部はさておき、ポイントは

「コーディング、自律作業、科学的推論のいずれでも、現行の最強モデルを明確に上回っている」

という事実です。

そのうえで、目を引くのはサイバーセキュリティ領域での跳ね方です。

Anthropic自身が比較例を出しているのですが、Firefoxの脆弱性をエクスプロイト化(攻撃に使える形に仕上げること)する作業について、Opus 4.6は数百回試行して成功したのが2回だけ。

一方Mythos Previewは、同じ脆弱性群から181個のエクスプロイトを生成し、さらに29ケースでレジスタ制御(より深い乗っ取りに繋がる段階)に到達した、と報告されています。脆弱性再現を測るCyberGymという業界ベンチマークでも83.1%。

ここで起きていることを補足すると、これまでAIモデルは「脆弱性を見つける」ことはある程度できても、「それを実際に動く攻撃コードに仕上げる」ところは苦手でした。

後者は人間の専門家の経験と勘に依存する部分が大きく、最後のひと押しが効かなかった。Mythos Previewは、その最後のひと押しまでかなりの確率でこなせる、ということです。「専門家にしかできなかったこと」が、モデルの内側にかなりの程度入り込んでいる、と言い換えてもいい。

さらにびっくりなエピソードもあります。

正式なセキュリティ訓練を受けていない社内エンジニアが、リモートコード実行(攻撃者が遠隔から相手のマシンを乗っ取れる類の脆弱性)の探索を「一晩」モデルに依頼し、翌朝には動作するエクスプロイトを受け取っていた——というものです。

これまで世界トップクラスのセキュリティ研究者が数週間から数カ月かけて取り組むような作業が、専門外の人間でもひと晩でこなせる範囲に入り始めている、ということになります。

Anthropicは、こうした能力を意図して訓練したわけではなく、コードと推論と自律性の改善から副次的に立ち現れたものだと書いています。

サイバー専用の特殊モデルではなく、汎用的に賢いモデルを作ったら、結果としてサイバー攻撃も得意になっていた、という説明です。

これまでのLLMの発展進化からすると、それほど驚くことではありませんが、人間が狙わなくてもどんどん全方位で賢くなっていくというのはおそるべきことでもあります。

だから一般公開しない、という判断

Anthropicの結論は明快でした。

これは一般公開しない。

Project Glasswingの技術解説では、主要なOSやWebブラウザを含む広範なソフトウェアから「数千件規模」の高・重大レベルの脆弱性、いわゆるゼロデイが見つかっており、その大半はまだ修正されていない、と説明されています。

ゼロデイというのは、開発元すら存在を知らない未知の脆弱性のことです。

対策が打たれるまでの「ゼロ日」しか時間がない、という意味からその名前がついています。攻撃者にとっては防御側がまだ気づいていない穴なので、もっとも価値が高い。公開されているゼロデイ買い取りプログラムを見ても、ブラウザやOSの高価値な脆弱性やエクスプロイトチェーンには数百万ドル規模の価格がつくことがあるとされています。それが「数千件」と聞けば、規模感としてはかなり異常です。

Anthropicの説明では、開発元によって実際に修正(パッチ適用)が完了したものは、報告されたバグの1%にも満たない、ともされています。だから責任ある開示(発見者がまず開発元に通知し、修正パッチが用意されてから公表するという業界慣行)の観点から、詳細は伏せざるを得ない、というロジックです。

「強いから出せない」という判断は、AIラボとしてはかなり踏み込んだ意思表示です。普通、性能の高い新モデルは商業的にも大きな価値を持つので、可能な限り早くAPIや製品を通じて広く使ってもらいたい、というのが業界の自然な力学です。それに逆らう形でアクセスを絞るのは、相応のロジックがなければ説明がつきません。Anthropicは「Mythosクラスのモデルを将来安全に大規模展開すること」を最終目標に据えつつ、そのための安全策を別系統(次のClaude Opus)で先に作り込む、と明言しています。

防御側に先に渡す、という設計

封印するだけでは終わりません。Anthropicは同じモデルを、防御側の有力プレイヤーに先行配備しています。

中心パートナーはAWS、Apple、Broadcom、Cisco、CrowdStrike、Google、JPMorgan Chase、Linux Foundation、Microsoft、Nvidia、Palo Alto Networksの11社にAnthropic自身を加えた12社。さらにクリティカルインフラを支える40以上の組織にもアクセスが提供されます。Anthropicは1億ドル分の利用クレジットと、オープンソースのセキュリティ団体への400万ドルの寄付も同時にコミットしました。

参加企業の顔ぶれを見れば、これは単なる研究発表ではないことがわかります。クラウド事業者(AWS、Google、Microsoft)、エンドポイントセキュリティ大手(CrowdStrike、Palo Alto Networks)、デバイスメーカー(Apple)、半導体(Nvidia、Broadcom)、ネットワーク機器(Cisco)、Linuxを支える非営利財団、そして金融大手(JPMorgan Chase)。ほとんどの人がインターネットを使うときに通る経路のどこかに必ず関わっている企業ばかりです。

Project Glasswingは、研究発表というより、現場投入を見据えた業界横断の運用枠組みです。発見、トリアージ(優先順位づけ)、開示、修正という一連のフローを、Mythosを軸にした共通基盤の上で回そうとしている、と読むのが素直だと思います。

起きそうなパラダイムシフト

ここまでの話で本当に重いのは、ゼロデイの数の多さそのものではないと感じます。

むしろ重要なのは、脆弱性の発見、切り分け、悪用可能性の検証という工程が、これまでよりはるかに短い時間で回り始めるかもしれない、という点です。

少し背景を補足します。これまでのサイバーセキュリティ運用は、ある種の「人手と時間の制約」の上に成り立ってきました。脆弱性を見つけるには熟練したセキュリティ研究者の労力が必要で、ひとつの重大な脆弱性を見つけるのに数週間から数カ月かかることも珍しくない。

攻撃者側も同じ制約の中にいるので、防御側には準備の時間がそれなりに残されていました。

「攻撃者がこの脆弱性に気づくまで、まだしばらくは大丈夫だろう」

という暗黙の前提が、運用設計の隅々に染み込んでいたわけです。

その前提が崩れる可能性が出てきています。AIが脆弱性発見からエクスプロイト作成までを自動化できるなら、攻撃側も防御側も、同じ時間軸で動くことができなくなる。

これまで「見つかった後どう直すか」が中心
だった議論は、

これからは「大量に見つかる世界をどう運用するか」
へ移っていくでしょう。

具体的には、こんな問いが現実味を帯びてきます。

• 自社でいま動いているソフトウェアの全リスト(資産インベントリ)は、本当に最新の状態に保たれているか。
• 新たな脆弱性情報が入ってきたとき、どれを最優先で対応するかの判断基準は明確か。
• 委託先のSIerやSaaSベンダーに脆弱性が見つかったとき、自社にどう連絡が来て、誰が一次判断を下すのか。
• 大量のアラートが押し寄せたとき、現場が燃え尽きずに回り続ける運用設計になっているか。

これらは、一見すると地味で、新技術の話とは関係なさそうに見えます。しかしAIで発見能力だけが劇的に上がっても、それを受け止める組織側の設計が伴わなければ、現場はアラートと修正タスクに押し流されて終わります。「強いツールを持っているのに、それを使い切る運用が組めていない」状態は、これまでも何度も見てきた光景です。

公益性と事業戦略の両面を持つ取り組みでもある

ここで一段引いて、Project Glasswingの位置づけも整理しておきます。

この取り組みは、クリティカルインフラの防御という公益性の高い目的を掲げる一方で、Anthropicの中長期的な事業展開とも整合する設計になっています。

Anthropic自身、最終的には「Mythosクラスのモデルを安全に大規模展開すること」を目標として掲げており、今回のGlasswingはそのための知見を蓄える段階として位置づけられています。

同ページでは、約90日後に学びを公開報告する予定であることや、将来的にはClaude API、Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundry経由でパートナー向けに提供範囲を広げていく方針も示されています。

防御用途という限定された文脈で先行配備することで、実運用に近い条件でデータと運用ノウハウが集まります。脆弱性発見からトリアージ、開示、修正支援に至る一連のフローの中で、Mythosが共通基盤として使われる土壌ができていく、という構造です。これは、AI業界全体で繰り返し見られてきたパターンでもあります。新しい基盤技術を提供する側は、最初に「どこで使うか」を設計した者が、そのまま事実上の標準として残りやすい。

これは批判的に見るべき話ではなく、公益性と事業性が両立しうる典型的な事例として読めるものだと思います。

報道では「強すぎて出せないモデル」という側面が強調されがちですが、実際の発表内容は、安全策の段階的な構築、パートナーとの責任分担、公開報告のスケジュールまでを含んだ枠組みの提示でした。

「封印」よりも「設計された先行配備」と捉えたほうが、全体像に近いと言えそうです。

それでも、まだ検証の途上にある

もうひとつ、冷静に置いておきたいことがあります。

印象的な成果の多くは、現時点ではAnthropic自身の説明に依拠しています。

修正済みが1%未満ということは、外部から独立検証しにくい状態が当面続く、ということでもあります。Anthropicは、198件のサンプルに対する手動レビューで89%のケースで重大度判定が完全に一致し、98%が1段階以内に収まっていたといった整合性データを示してはいますが、広範な第三者検証が完了したわけではありません。

「数千件の高・重大脆弱性」という数字は強烈ですが、読み方には少し慎重さがいります。妥当なのはおそらく、「かなり強いシグナルが出ているが、まだ全面的に検証済みとは言えない」あたりの理解です。

Anthropicは90日後に学びを公開報告すると約束しているので、そこまで含めて見届ける必要があるでしょう。

一次情報の内容は重く、同時に検証余地も残る——その中間に踏みとどまるのが、いまのところ妥当な距離感です。

おわりに：問いの重心はどこに移るのか

最初のニュースに戻ります。今回の出来事は、表面的にはサイバーセキュリティの話に見えます。

しかし、そこで露わになったのは、特定領域の問題というより、AIの能力水準そのものが新しい段階に入りつつある可能性だと思います。

Mythos Previewが目立ったのは、脆弱性探索という測りやすい領域だったからであって、そこで見えている変化は、研究開発、事業設計、経営判断といった他の知的業務にも波及しうるものだと捉えています。

言い換えると、今回の出来事が示しているのは、

これまでの延長線上では捉えにくいレベルの能力を持つAIが、すでに現実のものになりつつある

ということではないでしょうか。

そしてこの種の能力が特定の一社に長く閉じたままでいると考える理由は乏しく、今後は他社や他領域にも波及していく可能性を前提に置いて考えるべき局面だと思います。

そうなると、問いの立て方が変わってきます。

「このモデルをどう使うか」ではなく、

「高度な専門能力を一部領域で代替・補完しうるAIが現実味を帯びるなかで、自社は何を価値として提供する会社なのか」
のほうへ、重心が移っていきます。

業務プロセスを効率化する、という発想だけでは届かない射程の話です。

考えてみれば、これまで「AIに置き換わらない仕事」としてイメージされてきた領域（たとえば複雑な設計判断、高度な専門知識、長い文脈を踏まえた意思決定、創造的な問題解決など）は、まさにMythos Previewが頭角を現した領域と重なっています。
PhDホルダーの試験で94%を取り、熟練エンジニアが数週間かけていた作業を一晩でこなす。この事実を前にしたとき、

企業に問われるのは、
「AIにできないことを探す」という守りの思考ではなく、
「この賢さを前提にしたときに、自社の事業とチームは何を価値として残せるのか」という、もう一段上の問いだと思います。

それは技術論でも導入事例の話でもなく、事業そのものの設計論の話です。

もちろん、いまはまだ「Mythos Previewという一つのモデルの話」に見えるかもしれません。
そして、誇張として片づけるには一次情報が重く、既成事実として断定するにはまだ検証余地もある。
でも、そう見えているうちに自社の立ち位置を考え始められるかどうかが、次の局面でじわじわ効いてくる気がします。

本稿の論点について、自社の状況に引き寄せて考えてみたい、あるいは誰かと伴走しながら整理していきたい、といったご要望がございましたら、お問い合わせよりお気軽にお声がけくださいませ！
微力ながら、Qualitegもご一緒に考えさせていただければ幸いです。

── SaaS再編の時代に、どこにポジションを取るか

こんにちは！ Qualitegコンサルティングです！

ここ数年、「日本のAI戦略」というテーマでの相談やディスカッションが増えてきました。

生成AIの登場以降、経営層から現場のエンジニアまで、それぞれの立場で「自社はどこに張ればいいのか」「国としてはどう進むべきか」を模索している、というのが実感です。

本シリーズでは、その問いに対して少し腰を据えて向き合ってみたいと思い、前後編の構成で書いてみました。

前編では、国産LLM、データセンター投資、データ主権の3テーマを通じて、日本のAI投資が必ずしも「使われて勝つ構造」に向かっていない可能性を見てきました。投資の総額やプレイヤーの動きを並べてみると、号令の方向と実際の資金の流れにはちょっとしたズレがあるのではないか、という現在地が見えてきます。

後編では、その前提の上で視点をソフトウェア産業全体に広げます。もしAIによってアプリケーション層そのものの競争ルールが変わるなら、日本が張るべき場所もまた変わるはずです。海外で起きているSaaS産業の地殻変動を眺めたうえで、日本がどこにポジションを取るべきかを一緒に考えていきましょう。

第5章：ソフトウェア産業で何が起きているか

ソフトウェア株の急落──何が織り込まれたのか

2026年1月末以降、北米のソフトウェア／データ関連株には大規模な売りが波及しました。Reutersの報道によれば、S&P 500のソフトウェア・サービス指数は急落し、セクター全体の時価総額が約1兆ドル（約150兆円）近く減少したとされています。北米ソフトウェア銘柄を追跡するIGV ETFは年初来で2割前後の下落を記録し、セクターのバリュエーションは2010年代半ば以来の水準にまで圧縮されました。

背景として報じられたのは、生成AIがアプリケーション層の収益構造を侵食しうるという見方の再燃です。マクロ経済の急変や個別のスキャンダルではなく、ソフトウェア産業そのものの構造的な変化への警戒が売りを加速させた格好です。

ここで注意しておきたいのは、3つの切り分けです。

1つ目に、市場はそう織り込み始めた。SaaSの収益マルチプルは一部の大手を除くと厳しい水準に追い込まれ、勝ち組が平均を押し上げる二極化が進行中です。VC投資も2021年のピークからほぼ半減したのち横ばいが続く一方、案件数は大幅に減少しており、「少数の有望企業に大型の資金が集中し、それ以外は干上がる」構図が鮮明です。

2つ目に、実態がそこまで急速に進むかは未確定です。短期の株価は物語（ナラティブ）に振れやすい性質を持ちます。バリュエーションの調整が構造的なものなのか一時的なものなのかは、今後の推移を見る必要があります。

3つ目に、重要なのは未来の確定ではなく、競争条件の変化が広く意識され始めたことです。後述するように、課金モデル、UI、垂直統合といった複数の次元で、SaaSの前提が揺さぶられています。

「SaaS is Dead」の中身

2024年末、大手テック企業のCEOの発言が「SaaSは死んだ」と要約され拡散しました。IDCはこのテーマを整理した分析を公開しています。もちろん翌日からSaaS企業が消えるわけではありません。ただ、この言葉が象徴する変化は根深いものがあります。

ビジネスモデルへの転換圧力。 IDCの予測（FutureScape）では、2028年までにソフトウェアベンダーの70%がシートベース（ユーザー数課金）からコンサンプションベースやアウトカムベース（成果課金）への移行圧力にさらされるとされています（CIO.comの解説記事も参照）。

なぜか。シートベース課金は「何人がそのソフトを使っているか」で値段が決まります。ところがAIエージェントが人間の代わりにタスクを処理するようになると、「何人が使うか」という問い自体の説明力が相対的に落ちていきます。だから課金の基準は「どれだけ処理したか」（コンサンプション）や「どれだけの成果を出したか」（アウトカム）に移っていく可能性がある。

これはSaaS企業にとって、単なる価格改定ではなく、収益構造の根本的な組み替えを迫られることを意味します。シートベース課金の魅力は予測可能性にありました。ユーザー数×月額単価で来月の売上がかなり正確に見える。しかし成果課金になると売上の変動幅が大きくなり、SaaSの最大の魅力だった「予測可能な定期収入」が揺らぎます。投資家がSaaS銘柄に高いマルチプルをつけてきた根拠の一つがこの予測可能性だったわけで、それが失われるとなれば、バリュエーションが構造的に下がるのも理解できます。

インターフェースという「堀」の希薄化。 業界では「何百万人もの人がSaaSのUIを覚えたこと自体が最大の堀であり、インターフェースが自然言語になった瞬間にその堀は消える」という見方が広がっています。

考えてみてください。Salesforceの競争優位性の相当部分は、「何百万人もの営業担当者がSalesforceの使い方を知っている」という事実に由来しています。別のCRMに乗り換えようとすると、全員が新しいUIを覚え直す必要がある。この「学習コスト」が、実質的なスイッチングコストとして機能してきたわけです。

しかし、インターフェースが自然言語での指示へ寄っていくと、UI由来のユーザー体験の差分は相対的に縮まりやすくなります。UIの学習コストが下がれば、スイッチングコストも下がる。何年もかけて築いた参入障壁が無効化されるかもしれない。これが現実になるかどうかはまだわかりませんが、市場がかなり本気でその可能性を織り込み始めたのが2026年初頭の動きだと見ることができます。

基盤モデル企業がアプリ層まで降りてきた

もう一つ見逃せない動きがあります。

2024年から2025年前半は「AIは既存SaaSを強化する」が主流のナラティブでした。どのソフトウェア企業も決算説明会で「AI組み込みで生産性アップ」と語り、投資家もそれを好感していた。ところが2025年後半から2026年にかけて、このナラティブが静かにひっくり返ります。

転換の背景にはいくつかの要因が指摘されています。AIエージェント系のスタートアップが実用的な製品を出し始めたこと。DeepSeekに代表されるオープンソースモデルが、低コストでも競争力のある性能を達成しうることを示したこと（Reuters: A year on from DeepSeek shock）。そして決定的だったのは、基盤モデル企業自身がアプリケーション層に進出し始めたことです。

OpenAIはGPTsやCanvasを提供。AnthropicはArtifacts、Computer Use、MCP、Claude Codeと、次々にアプリケーション層の製品を展開しています。さらに非エンジニア向けのデスクトップエージェント──ブラウザ操作、Excel操作、ファイル管理を自律的に行うツール──も登場しています。

なぜこうなるかというと、基盤モデルだけの商売は差別化が難しいからです。モデルの性能差は時間とともに縮まり、価格競争に陥りやすい。だからモデルの上に付加価値の高いアプリケーション層を構築して、ユーザーのワークフローに深く入り込むことでスイッチングコストを作りたい。

これは「垂直統合の誘惑」とでも呼ぶべき現象で、テック業界では過去に何度も繰り返されてきたパターンです。チップメーカーがOSを作り、OSメーカーがアプリを作り、アプリメーカーがクラウドを作る。AI業界でも同じことが起きているだけ、とも言えます。

「基盤モデルは海外製でいい、その上にアプリを作るのが自分たちの仕事だ」と考えていたプレイヤーにとっては、悩ましい状況です。上のレイヤーで付加価値を出すつもりだったのに、下から浸食されてくる。

では、この環境下で守りやすいポジションはどこにあるのか。

第6章：構造的に守りやすい場所はどこか

AIベンダー自身が担うと利益相反が生じやすい領域を探す

基盤モデル企業がどれだけ進化しても、ベンダー自身が担うと利益相反が生じやすい領域というのはあります。なぜなら、ある種のサービスは「特定のAIベンダーに属さない」ことが本質的な価値だからです。

その視点で市場を眺めてみると、独立系プレイヤーに機会がある可能性のある候補がいくつか浮かんできます。

マルチベンダー統合。 OpenAIはAnthropicのモデルを推薦しませんし、GoogleはOpenAIとの併用を手助けしてくれません。しかし企業にとっては、タスクごとに最適なモデルを選べるほうが合理的なケースが多い。しかもLLMの世界では、用途別に優位なモデルが比較的頻繁に変動します。コーディング、長文コンテキスト処理、推論、多言語対応──それぞれの評価軸で最適なモデルは異なりますし、数カ月で勢力図が塗り替わることも珍しくありません。

たとえば、法務文書のレビューにはモデルA、社内ナレッジ検索にはモデルB、コード生成にはモデルCを使っている企業があったとして、アプリケーション側を変えずにモデルだけを切り替えられる基盤があれば、ベンダーロックインのリスクを下げられます。各AI大手にとって利益相反があるぶん、こうしたベンダーニュートラルな統合レイヤーには独立系プレイヤーに構造的な余地があります。

データ統制・ガバナンス。 前編で触れたデータ主権の話と直結します。LLMの入出力データの監視を、そのLLMを提供している企業に委ねるのは、審判と選手を兼ねてもらうようなものです。

特に規制が厳しい金融、医療、官公庁向けでは、「どのLLMを使っていても、入出力データが適切に管理されていることを独立して検証できる」仕組みへのニーズは根強いでしょう。具体的には、機微情報をマスクしてからLLMに送る仕組みや、モデル非依存で監査ログを残す仕組みです。これは「国産モデルを使うことでデータを守る」というアプローチとは根本的に発想が違います。モデルの国籍ではなく、データの流れそのものを制御する。「モデルの外側に置くセキュリティレイヤー」です。

業務コンテキストへの接続。 汎用AIエージェントがどれだけ賢くなっても、個々の企業の稟議フロー、社内規定、業界固有の規制は知りません。「1,000万円以上の支出は部長承認、5,000万円以上は役員承認」「薬機法の広告規制に抵触しないか確認が必要」──こうした業務コンテキストは、企業ごと、業界ごとに千差万別です。

たとえばAIエージェントに「契約書をレビューして」と頼んだとき、法的なチェックはかなり正確にやってくれます。しかし「この条項はうちの過去の取引慣行に照らしてどうか」「この相手先との力関係を考えるとどこまで押せるか」といった判断は、その企業の文脈を深く知らないとできません。稟議ルール、承認権限、過去の社内判断──こうした制約条件をエージェントに与える設計こそが、業務を深く理解したプレイヤーでないと埋められない「ラストワンマイル」です。

この3つに共通するのは、いずれもAIベンダー側ではなく、AIを利用する企業の側に立つことで初めて提供できるという点です。AI大手が進化すればするほど、「AI大手の代替」ではなく「AI大手と企業の間に立つ」ポジションの価値は、むしろ上がるかもしれません。

もちろん、これが確実に正しいとは誰にも言えません。AIベンダーが自前でこうした領域もカバーしてしまう可能性もありますし、企業側がこうした中間レイヤーを必要としない運用形態に落ち着く可能性もある。ただ、少なくとも現時点の構造を見る限り、検討に値する方向性ではあると思います。

SaaSモデルの再編圧力──そのあとに何が来るか

「SaaS is Dead」の議論をもう少し先まで考えてみましょう。

仮に現在のSaaSモデルが大幅に縮小するとして、その後に来るのは何か。いくつかのシナリオが考えられます。

一つは「AIエージェントが直接タスクを実行するモデル」。ユーザーがソフトウェアを操作するのではなく、AIエージェントに目的を伝え、エージェントがさまざまなツールやデータソースを組み合わせて結果を返す。この場合、従来のSaaSの「画面」は不要になり、代わりにAPIやデータパイプラインの重要性が上がります。

もう一つは「プラットフォーム型への集約」。数社のAI大手が提供するプラットフォーム上に、あらゆるビジネスツールがプラグインとして載る世界です。

いずれのシナリオでも、重要なのは「データとワークフローの独自性」です。AIがどれだけ賢くなっても、企業固有のデータと業務プロセスは外部からは見えない。このデータとプロセスへのアクセスを持つプレイヤーは、AIの進化の恩恵を受ける側に回れます。逆に、汎用的な機能を提供しているだけで独自のデータもワークフローも持たないSaaS企業は、AIエージェントに置き換えられるリスクが高い。

第7章：日本の勝ち筋はどこにあるか

「作れない」は本当に弱みか

前編で見た通り、基盤モデルの開発競争で日本が米中に勝つのは、資本の桁が違う以上、現実的には難しい。では「作れない」ことは致命的な弱みなのかというと、そうでもないかもしれません。

よく引き合いに出される話ですが、トヨタ生産方式が世界の自動車産業を変えたのは、エンジン性能で圧倒したからではなく、同じエンジンの「使い方の設計」──生産プロセス、品質管理、サプライチェーン──で差別化したからでした。「ジャスト・イン・タイム」や「カイゼン」といった生産システムの設計で、同じ部品から圧倒的に高い品質と効率を引き出した。自動車とAIではいろいろ条件が違いますから、安易なアナロジーには注意が必要です。ただ「道具を作る競争」と「道具で何を解くかの競争」は別物だ、という構図自体は参考になります。半導体の歴史でも、日本はチップの「製造」では韓国・台湾勢に追い抜かれましたが、製造装置や素材ではいまだに高いシェアを維持しています。

AIでも似たポジショニングがありえるとすれば、それは「モデルを作る」ことではなく、「モデルを使いこなすための基盤やツール」を作ることかもしれません。

"AIユースケース先進国"という可能性

日本にはAIが解くべき課題がたくさんある、とよく言われます。超高齢社会と人手不足。製造業の品質管理と自動化。医療・介護の効率化。建設業の安全管理。物流の最適化。行政のデジタル化。 たとえば、製造現場での異常検知と作業標準の照合、介護現場での記録業務とケア計画支援、建設現場での安全書類チェックと規程照合などは、日本で先に実装知見が蓄積されやすい領域でしょう。

しかもこれらの現場には数十年分のデータとノウハウが蓄積されていて、「人手が足りないからAIを入れざるを得ない」という切実な動機がある。「AIを使ってみたい」ではなく「AIを使わないとオペレーションが回らない」というレベルの切迫感です。

労働人口の減少は、国立社会保障・人口問題研究所の将来推計人口（令和5年推計）を見ると深刻さが際立ちます。生産年齢人口は今後20年間で大幅な減少が見込まれており、推計の前提条件によって幅はあるものの、数千万人規模の縮小が予測されています。これは「生産性を上げないと社会が回らない」ということであり、AI導入のインセンティブとしてはこれ以上ないほど強烈です。

日本の優位は、モデルの供給側ではなく、制約の多い現場でAIを回す実装側にあるかもしれません。ただ、課題があることと、その課題をAIで解く力があることは別の話です。課題は豊富にあるけれど実装力が足りない、では宝の持ち腐れです。

実装力を育てるには何が必要か。まずAI活用の設計ができる人材。モデルの中身を理解し、業務プロセスとの統合を設計できる人です。次に、マルチベンダーでLLMを安全に使いこなすための基盤。そしてデータ統制とガバナンスの仕組み。成功パターンの共有と横展開。だからこそ、投資の優先順位が問われます。基盤モデルの自前開発に予算を割くのか、それとも「どんなモデルでも使いこなせる基盤」と「それを担える人材」に振るのか。どちらが費用対効果が高いかは、考えてみる価値のある問いだと思います。

使い方で輸出する

高齢化や人手不足はアジア全域で今後急速に顕在化する課題です。韓国、中国、タイ、ベトナム──いずれも20〜30年後には日本と似た人口構造の課題に直面します。日本がここでAI実装のノウハウを蓄積できれば、それ自体が輸出可能な知的資産になりえます。

モデルは海外製、使い方は日本式。「日本式AI活用」のパッケージ化という絵は、少なくとも検討に値するシナリオではないでしょうか。

製造業の品質管理にAIをどう組み込むか。高齢者介護のオペレーションをAIでどう最適化するか。建設現場の安全管理をAIでどう強化するか。こうしたドメイン特化の実装ノウハウは、基盤モデルを持っているだけでは生まれません。現場のデータと業務知識を持ち、それをAIに接続する設計力が必要です。

もちろん「基盤モデルを全くやるな」という話ではなく、防衛・インテリジェンスのように国産が不可欠な領域はありますし、研究開発の継続にも価値がある。100Bモデルの開発経験はモデルの内部動作の理解を深め、活用側のスキルにもフィードバックされます。ただ、リソース配分の重心をどこに置くか、という議論はもっとあっていいと思います。

第8章：おわりに

前後編を通じて、けっこう率直なことを書いてきました。

国産LLMの売上構造。SIerの多重委託構造と人月商売の矛盾。DC需要の実態と「面にならない」GPU需要。米国との投資規模の桁違い。データ主権議論の飛躍。SaaS産業の地殻変動と大規模な時価総額の調整。基盤モデル企業のアプリ層進出。

居心地のいい話ばかりではなかったかもしれません。

ただ、見方を変えれば、日本には課題があり、データがあり、現場がある。刀を打つ勝負では分が悪いかもしれないけれど、刀の使い手としてなら、まだまだやれることはたくさんあるはずです。

使いこなす力を磨くのか、作る力にこだわるのか。その選択が、これからの数年間でかなり効いてくるのではないかと思っています。

この2本の記事を通じて見てきた構造から、企業としてまず考えるべきことがあるとすれば、単一モデルを前提とした設計を避けること、モデルの選定よりも先に業務設計とガバナンスの枠組みを置くこと、そして自前のモデル開発よりも、どんなモデルでも使いこなせる基盤とそれを担える人材への投資を厚くすることです。これが唯一の正解だとは言いませんが、少なくとも検討のテーブルには載せる価値があるはずです。

本稿で提示した3つの論点——マルチベンダー統合、データ統制・ガバナンス、業務コンテキストへの接続——は、基盤モデルの進化とアプリケーション層の再編が同時進行する構造変化のなかで、企業がAIを持続的な競争優位へと転化していくうえで避けて通れない戦略的要点であると、私たちは捉えています。

Qualitegは創業以来、先端AIの研究開発と事業実装の双方からこの問いに一貫して向き合い、技術と戦略の両輪でクライアントの意思決定を支えてまいりました。

私たちは、20種類以上のLLMを単一の基盤から切り替え可能にするエンタープライズLLMプラットフォームBestllam®、LLMの入出力を監査し情報漏洩を検出・遮断するLLM-Audit™、機微情報を高速・高精度に検出・匿名化するPII-Fi™を自社開発・運用しています。いずれも、特定のAIベンダーに属さない独立した立場だからこそ提供できる基盤として設計してきました。

同時に、外資系コンサルティングファームやグローバル企業での事業開発・技術戦略の経験を持つメンバーが、ビジネスコンサルティングとAIテクノロジーコンサルティングを通じて、戦略立案から技術検証、実装、現場定着までを一貫して担っています。戦略を描く段階から技術者が同じテーブルに座ることで、技術的実現性と事業的合理性を両立した、地に足のついた設計を心がけています。

AIをどう事業に載せるか——この問いに取り組まれている企業の皆さまの一助となれるよう、私たちも戦略と技術の両面からご一緒できればと考えております。

ご相談やディスカッションのご要望がございましたら、お問い合わせよりお気軽にお声がけください。

こんにちは！Qualitegプロダクト開発部です！

PyCharmの内蔵npmツールで npm start を実行した瞬間、何のエラーメッセージもなくIDEが消える。

再起動してもう一度試すとまた落ちる。ログを見ても手がかりがない——。

今回はこの「サイレントクラッシュ」に遭遇し、原因の絞り込みから回避策の確立まで至った過程を書き残しておきます。同じ現象で困っている方の参考になれば幸いです。

環境

上記のとおり、PyCharmは執筆時点の最新版(2026.1)となります。

確認できたこと・推測していること

まず最初に、この記事で述べる内容の確度を整理しておきたいとおもいます

確認できたこと

• npmツール内蔵ターミナル経由でのみクラッシュが再現する（外部ターミナルでは再現しない）
• ConPTYを無効化すると回避できる
• idea.log、JVMクラッシュダンプともに有力な痕跡がない
• インストール先のパスに旧バージョン名（PyCharm 2023.1.6）が残っている
• conpty.dll が旧バージョンのパスからロードされている

推測していること

• 上書きアップデートに伴うネイティブコンポーネントの不整合が関与している可能性がある
• conpty.dll 周辺の互換性問題である可能性が高い
• 大量のコンソール出力時にだけ顕在化するネイティブ層の異常と考えられる

conpty.dll の新旧バージョンの差分比較やクラッシュダンプの詳細解析までは行っていないため、根本原因については状況証拠に基づく推測となりますが、
切り分けの結果としてConPTY周辺が原因である可能性は非常に高いと判断しています。

症状の詳細

PyCharmのnpmツール内蔵ターミナルで npm start を実行すると、数秒以内にPyCharmのウィンドウが消えます。タスクバーからも消え、プロセスも終了しています。再現率はほぼ100%でした。

特徴的だったのは以下の点です。

• エラーダイアログが一切表示されない
  JetBrains標準のクラッシュ通知も出ません。ウィンドウが文字通り「消える」だけです。
  
• idea.logにクラッシュの痕跡がない
  正常に起動・インデックス完了した後、ログがプツッと途切れています。
  
• Pythonスクリプトの実行では問題が起きない
  Run ConfigurationからPythonを実行する分には安定しています。
  
• コマンドプロンプトから npm start してもPyCharmは落ちない。
  外部ターミナルを使えば問題なく動作します。

最後の点が最も重要な切り分けポイントとなります。

ログに何も残らないサイレントクラッシュの難しさ

通常、PyCharm（IntelliJ系IDE）がクラッシュすると、idea.log にJavaレベルの例外が記録されるか、JVMクラッシュダンプ（java_error_in_pycharm_*.log）がユーザーのホームディレクトリに生成されます。

今回はそのどちらにも有用な情報がありませんでした。これはJava層ではなく、もっと低いレイヤー——ネイティブコード層でプロセスが異常終了している可能性を示唆しています。JVMがクラッシュダンプを書く暇もなく終了させられている状態です。

ログに何も残らないため、「何を変えたら再現しなくなるか」を1つずつ試す切り分けテストが唯一の手段でした。

ログの場所について補足

なお、PyCharmのログと設定は別々のディレクトリに保存されています。ログは %LOCALAPPDATA%（AppData\Local）、設定は %APPDATA%（AppData\Roaming）です。ネット上では %APPDATA% としか書かれていないことが多く、Roamingを探して「ない！」となるケースがよくあります。

ログ:  %LOCALAPPDATA%\JetBrains\<バージョン>\log\
設定:  %APPDATA%\JetBrains\<バージョン>\

一番手軽なのは Help → Show Log in Explorer です。2025年以降のバージョンでは Help → Diagnostic Tools → Special Files and Folders で全ディレクトリのフルパスが一覧表示できるので、こちらも便利です。

idea.log から読み取れた手がかり

クラッシュの瞬間は記録されていませんでしたが、idea.logからはいくつかの間接的な手がかりが得られました。

インストールパスと設定パスの不一致

Djb.vmOptionsFile=C:\Users\ml\AppData\Roaming\JetBrains\PyCharm2026.1\pycharm64.exe.vmoptions
Djna.boot.library.path=C:\Program Files\JetBrains\PyCharm 2023.1.6/lib/jna/amd64

設定ファイルのパスセレクタは PyCharm2026.1 なのに、インストール先は PyCharm 2023.1.6 のままです。

これは、長年の上書きアップデートによって環境の一貫性が崩れていることがわかります。ネイティブバイナリが想定通りに更新されていない可能性を疑う材料になりました。

ConPTYのロード元

Loaded bundled ConPTY from C:\Program Files\JetBrains\PyCharm 2023.1.6\lib\pty4j\win\x86-64\conpty.dll

npmツール内蔵ターミナルが使用する conpty.dll が旧バージョンのパスからロードされています。PyCharm 2026.1が想定するバージョンと一致しているかどうかは確認できていませんが、パスの不自然さは気になる点です。

node_modules の大量ファイル登録

NodeModulesDirectoryManager - Contributed {
  allCalculationsDuration: 2263 ms,
  allIncludedFileCount: 45078,
  allRootsWorkspaceModel: 42960,
  ...
}

45,078ファイルがインデックス対象として登録されていました。

最初はこれがクラッシュの原因ではないかと疑いましたが、node_modules をExcludedに設定してもクラッシュは解消しませんでした。(実はexcludedにしても、librootにしてるとインデックスしちゃう事象がありますので、excludedの効能が正直理解しきれていない面もあります）パフォーマンスの問題ではありましたが、クラッシュの直接原因ではなかったようです。

JVMメモリ設定の重複

-Xms256m, -Xmx2048m, ..., -Xmx8192m

-Xmx がうっかり2回指定されていました（後者が有効なので動作上は問題なし）。これ自体はクラッシュの原因ではありませんが、設定ファイルの引き継ぎにも一貫性のなさが見え、環境全体に違和感があることを示していました。

切り分けテストと原因の絞り込み

テスト1: 外部ターミナルから npm start を実行する

PyCharmを開いた状態で、外部のコマンドプロンプトから npm start を実行したところ、PyCharmは落ちませんでした。

これにより、問題が npm start 自体ではなく、PyCharmのnpmツール内蔵ターミナルを経由して実行したときだけ起きることが確認できました。

この1つのテストで、疑わしい範囲が一気に狭まりました。

テスト2: ConPTYを無効化する

次は、PyCharmの内部レジストリ設定で terminal.use.conpty.on.windows を false に変更し、npmツール内蔵ターミナルから npm start を実行しました。

結果、クラッシュしなくなりました。

この2つの切り分けから、問題がConPTY周辺にあることはほぼ確実と判断しました。

ConPTYの無効化手順

Settings（設定画面）のTerminalセクションにはConPTYのオン・オフ項目がないため、内部レジストリから変更する必要があります。

1. Help → Find Action（Ctrl+Shift+A）を開く
2. Registry と入力してEnterを押す
3. レジストリ画面の検索欄に terminal.use.conpty.on.windows と入力する
4. 該当項目のチェックボックスをオフにする
5. PyCharmを再起動する

これでターミナルはConPTYではなく旧方式のWinPTYで動作するようになります。カラー出力の品質が若干落ちる場合がありますが、安定性は大幅に向上します。

なぜConPTYで落ちるのか（推測）

ここからは状況証拠に基づく推測です。裏付けとなるクラッシュダンプの解析やDLLのバージョン比較は行っていないため、その前提で読んでいただければと思います。

ConPTY（Windows Pseudo Console）は、Windows 10 バージョン1809で導入された仮想端末APIで、従来のWinPTYに代わりカラー出力やUnicode対応を改善した仕組みです。VS Code、Windows Terminal、JetBrains系IDEの内蔵ターミナルなどで採用されています。

npm start で起動するNode.jsの開発サーバーは、コンパイルログやHMR通知などを大量かつ高速にコンソールへ出力します。ConPTYはこの出力をPyCharmのJavaプロセスに中継する役割を担っています。

今回の環境では、PyCharm 2026.1が PyCharm 2023.1.6 のフォルダにインストールされており、conpty.dll も旧パスからロードされていました。上書きアップデートではすべてのネイティブバイナリが確実に更新される保証がないため、新しいターミナルエンジンと conpty.dll の間で何らかの不整合が生じ、大量出力時にネイティブ層で異常終了に至っている——というのが現時点での仮説です。

idea.logに記録が残らないのも、この仮説と整合的です。クラッシュがJVMの管理外のネイティブコードで発生している場合、JVMのエラーハンドラ自体が呼ばれず、ログを書く余地がないためです。

より確度の高い原因特定を行うのであれば、Windows Event ViewerでのApplication Errorの確認、ProcMonによるDLLロードのトレース、conpty.dll のファイルバージョン比較などが有効な次のステップになると思います。

複合的な条件で発生する問題

今回の問題は、複数の条件が重なって初めて顕在化するタイプのものでした。

どれか1つの条件を外すだけでクラッシュは回避できます。裏を返すと、再現条件の特定が難しく、「環境によって起きたり起きなかったりする」ように見える厄介な問題でもあります。

再発防止のための対策: クリーンインストール

ConPTYの無効化は１つの回避策ですが、そもそもネイティブコンポーネントの不整合が関与しているのであれば、クリーンインストールで解消される可能性が高いと考えています。

結局それかよって感じですが、やっぱりクリーンインストールするのが一番手っ取り早く効果があられるかもしれません。

1. PyCharmをアンインストールする
2. C:\Program Files\JetBrains\PyCharm 2023.1.6\ フォルダが残っていれば手動で削除する
3. PyCharm 2026.1を新規インストールする

設定ファイルは %APPDATA%\JetBrains\PyCharm2026.1\ に保存されており、アンインストールしても消えないため、再インストール後に自動的に引き継がれます。

また、JetBrains Toolbox Appを使ってインストール・アップデートを管理すると、バージョンごとに独立したディレクトリにインストールされるため、今回のようなパスの不整合が起きにくくなります。

教訓

1. サイレントクラッシュには切り分けテストが最も有効

ログに情報がない場合、ログをいくら睨んでも答えは出ません。「何を変えたら再現しなくなるか」を1つずつ試す切り分けが最も効果的です。今回は「内蔵ターミナルか、外部ターミナルか」という1つの切り分けで原因の範囲を大幅に絞り込めました。

2. Updaterによる上書きアップデートには（案外）リスクがある

JetBrains系IDEに限らず、メジャーバージョンをまたぐ上書きアップデートは予期しない問題を引き起こすことがあります。特にネイティブバイナリが関わる場合、古いファイルが残ることで新旧の不整合が生じる可能性があります。メジャーアップデートの際はクリーンインストールを検討すべきです。

3. 「確認できたこと」と「推測していること」を分ける

これは今回きづいた教訓というか、先輩方に指摘されたことですが、トラブルシューティングの記録を残すとき、切り分けで確認した事実と、状況証拠からの推測を明確に分けておくことが大切です。
事実と推測を混ぜてしまうと、後から振り返ったときに「結局何がわかっていて何がわかっていないのか」が曖昧になってしまいます。

4. テレメトリデータも情報源になる

PyCharmが出力するworkspaceModelのメトリクスからは、ファイルインデックスの規模やメモリ使用状況など、idea.logだけではわからない情報が得られます。今回はこのデータから node_modules の大量ファイル登録を把握できました。結果的にクラッシュの直接原因ではありませんでしたが、パフォーマンス改善のための有益な情報でした。

まとめ

• PyCharmのnpmツール内蔵ターミナルで npm start を実行するとIDEがクラッシュする問題に遭遇しました。
• idea.logにもJVMクラッシュダンプにも記録が残らないサイレントクラッシュでした。（ただし、再現性が高かったのでわりと切り分けがしやすくてそこは助かりました）
• 切り分けの結果、ConPTY周辺が原因である可能性が非常に高いと判断しました。
• 上書きアップデートによるネイティブコンポーネントの不整合が関与していると推測しています（conpty.dll の新旧差分までは未検証）。
• レジストリで terminal.use.conpty.on.windows を無効化することで回避できます。
• 再発防止にはPyCharmのクリーンインストールが有力な対策です。

ログに何も残らない問題のデバッグは心が折れそうになりますが、AIの力もかりつつ地道な切り分けが結局は一番の近道だとおもいます。
同じ現象で困っている方の助けになれば嬉しいです。

それでは、次回またお会いしましょう！

こんにちは、今回はシリーズ第6回トラブルシューティング - よくある問題と解決方法 について解説いたします！

さて、前回（第5回）は、統合Windows認証がブラウザでどのように動作するかを解説しました。

「イントラネットゾーン」という概念を理解することで、同じサーバーでもURLの書き方（NetBIOS名、FQDN、IPアドレス）によって認証動作が変わる理由が明確になったかと思います。また、Chrome/Firefoxではデフォルトで統合認証が無効になっている理由と、グループポリシーによる一括設定方法も学びました。

しかし、設定が完璧なはずなのに「なぜかうまく動かない」という場面は、実際の現場では必ず訪れます。

「最近、ファイルサーバーへのアクセスが遅い」「金曜日は使えたのに、月曜日の朝にログインできない」「特定のサービスだけKerberosが失敗する」——これらはヘルプデスクに日々寄せられる典型的な問い合わせです。

原因はKerberosの失敗、時刻のずれ、SPNの設定ミス、DNS関連の問題など多岐にわたりますが、体系的にトラブルシューティングすることで必ず解決できます。

今回は、AD環境で頻繁に起きるトラブルをパターン別に整理し、診断コマンドを使った原因特定から具体的な解決手順まで、実践的なトラブルシューティングの流れを解説します。焦らず、一つずつ確認していくことが解決への近道です。それでは始めていきましょう！

連載の構成

• 第1章：基本概念の理解 - Active DirectoryとKerberos/NTLM認証の基礎
• 第2章：ドメイン環境の構築 - 検証環境の構築手順
• 第3章：クライアントとサーバーのドメイン参加 - ドメイン参加の詳細手順
• 第4章：プロキシサーバーと統合Windows認証
• 第5章：ブラウザ設定と認証 - 各ブラウザでの設定方法
• 【★今回です★】第6章：トラブルシューティング - よくある問題と解決方法
• 第7章：セキュリティとベストプラクティス - 本番環境での考慮事項
• 第8章：実践的な構成例 - AIセキュリティツールとの統合事例

第6章：トラブルシューティング

6.1 認証関連のトラブル

6.1.1 Kerberosが失敗してNTLMにフォールバックする原因

Kerberosは最も安全な認証方式ですが、様々な理由で失敗し、NTLMにフォールバックすることがあります。これは、パフォーマンス低下の原因にもなります。

【典型的な症状】
ユーザー：「最近、ファイルサーバーへのアクセスが遅いんです」
IT管理者：「ログを確認してみましょう」

イベントログ：
Kerberos認証に失敗しました。
NTLMにフォールバックします。

IT管理者：「Kerberosが失敗してますね。原因を調べましょう」

診断コマンドの実行を見てみましょう。

【Kerberos診断】
# 現在のチケット確認
klist

結果（正常な場合）：
キャッシュされたチケット: 2
#0> クライアント: tanaka_t @ JP.QUALITEG.COM
    サーバー: krbtgt/JP.QUALITEG.COM @ JP.QUALITEG.COM
    暗号化の種類: AES-256-CTS-HMAC-SHA1-96
    チケットの有効期限: 2024/01/20 18:00:00

結果（問題がある場合）：
キャッシュされたチケット: 0
→ チケットが取得できていない

# チケット取得のテスト
kinit tanaka_t@JP.QUALITEG.COM

よくある原因1：DNS関連の問題を見てみましょう。

【DNSが原因の場合】
状況：NetBIOS名では動くが、FQDNでは失敗

テスト：
# NetBIOS名
ping fileserver → 成功
アクセス: \\fileserver\share → 成功（NTLM）

# FQDN
ping fileserver.jp.qualiteg.com → 成功
アクセス: \\fileserver.jp.qualiteg.com\share → 遅い（Kerberos失敗→NTLM）

原因調査：
nslookup fileserver.jp.qualiteg.com
→ 正引きOK

nslookup 192.168.1.50
→ 逆引きNG！

IT管理者：「逆引きDNSレコードが missing です」

解決策：
DNSマネージャーで逆引きゾーンにPTRレコード追加
50.1.168.192.in-addr.arpa. → fileserver.jp.qualiteg.com.

よくある原因2：SPN（Service Principal Name）の問題を見てみましょう。

【SPNが原因の場合】
症状：特定のサービスだけKerberosが失敗

確認コマンド：
setspn -L fileserver

結果（問題なし）：
登録されたSPN:
    HOST/fileserver
    HOST/fileserver.jp.qualiteg.com

結果（問題あり）：
登録されたSPN:
    （空）

または重複エラー：
setspn -X
重複したSPNが見つかりました：
    HTTP/intranet.jp.qualiteg.com
    → サーバーAとサーバーBの両方に登録

解決策：
# SPN追加
setspn -A HOST/fileserver.jp.qualiteg.com FILESERVER$

# 重複削除
setspn -D HTTP/intranet.jp.qualiteg.com サーバーB

暗号化方式の不一致も見てみましょう。

【暗号化の非互換性】
Windows Server 2019管理者：「新しいDCを追加したら認証が遅くなった」

調査：
# サポートされる暗号化方式の確認
グループポリシー：
ネットワークセキュリティ: Kerberos で許可された暗号化方式の構成

古いサーバー：RC4-HMAC（非推奨）
新しいサーバー：AES256-CTS-HMAC-SHA1-96

問題：
古いアプリ：「RC4しか話せません」
新DC：「RC4は無効化されています」
結果：Kerberos失敗

解決策：
1. 一時的にRC4を有効化（セキュリティリスクあり）
2. アプリケーションのアップデート（推奨）

6.1.2 時刻同期の重要性

Kerberos認証において、時刻同期は極めて重要です。5分以上のずれがあると認証が失敗します。

【時刻ずれによる認証失敗】
月曜日の朝：
田中：「金曜日は使えたのに、ログインできません！」
エラー：「現在、ログオン要求を処理できるログオンサーバーはありません」

IT管理者：「時刻を確認してみましょう」

クライアントPC：2024/01/20 09:00:00
DC：2024/01/20 09:07:00
差：7分

IT管理者：「5分以上ずれてます。これが原因です」

時刻同期の仕組みを理解しましょう。

【Windows時刻同期の階層】
正しい構成：
インターネット時刻サーバー（time.windows.com）
    ↓
PDCエミュレーター（DC01）
    ↓
その他のDC（DC02, DC03）
    ↓
メンバーサーバー、クライアントPC

確認コマンド：
# 時刻源の確認
w32tm /query /source

正常：DC01.jp.qualiteg.com
問題：Local CMOS Clock → 同期していない

# 詳細状態
w32tm /query /status

時刻同期の修正方法を見てみましょう。

【時刻同期の設定】
PDCエミュレーターでの設定：
# 外部時刻源の設定
w32tm /config /manualpeerlist:"time.windows.com,0x9 ntp.nict.jp,0x9" /syncfromflags:manual /reliable:yes /update

# サービス再起動
net stop w32time && net start w32time

# 即座に同期
w32tm /resync /rediscover

その他のDCでの設定：
# PDCエミュレーターから同期
w32tm /config /syncfromflags:domhier /update

クライアントPCでの設定：
# 通常は自動だが、手動設定も可能
w32tm /config /syncfromflags:domhier /update

時刻同期のトラブルシューティングを行いましょう。

【よくある時刻同期の問題】
問題1：ファイアウォールでNTPがブロック
症状：
w32tm /stripchart /computer:time.windows.com
エラー: 0x800705B4 - タイムアウト

解決：
UDP 123番ポートを開放

問題2：仮想マシンの時刻同期競合
症状：
VM：「ホストと同期します」
DC：「いや、NTPと同期して」
結果：時刻が安定しない

解決：
VMware: VMware Toolsの時刻同期を無効化
Hyper-V: 統合サービスの時刻同期を無効化

問題3：大幅な時刻ずれ
症状：
w32tm /resync
コンピューターの再同期コマンドがコンピューターに送信されましたが、
時刻データが利用できなかったためにエラーが発生しました。

原因：差が大きすぎて自動修正を拒否（通常48時間以上）

解決：
# 手動で近い時刻に設定してから同期
net time \\DC01 /set /y

6.1.3 SPN（Service Principal Name）の設定

SPNは、Kerberos認証でサービスを一意に識別するための名前です。正しく設定されていないと、Kerberos認証が失敗します。

【SPNとは何か】
新人：「SPNって何ですか？」
IT管理者：「サービスの住所みたいなものです」

例えで説明：
田中さんの自宅 = HOST/tanaka-pc.jp.qualiteg.com
　場所：tanaka-pc.jp.qualiteg.com
　用途：HOST（コンピューター）

会社のWebサーバー = HTTP/intranet.jp.qualiteg.com
　場所：intranet.jp.qualiteg.com  
　用途：HTTP（Webサービス）

Kerberos：「HTTP/intranet.jp.qualiteg.comへのチケットをください」
KDC：「SPNを検索...見つかった！チケット発行」

SPNの確認と登録を行いましょう。

【SPNの管理】
# 特定のアカウントのSPN確認
setspn -L IIS_Service

# コンピューターアカウントのSPN確認  
setspn -L SERVER01$

典型的なSPN：
HOST/server01
HOST/server01.jp.qualiteg.com
TERMSRV/server01
TERMSRV/server01.jp.qualiteg.com
RestrictedKrbHost/server01
RestrictedKrbHost/server01.jp.qualiteg.com

# IISサーバーのSPN登録例
# アプリケーションプールが特定のアカウントで実行される場合
setspn -A HTTP/webapp.jp.qualiteg.com JP\webapp_svc
setspn -A HTTP/webapp JP\webapp_svc

SPN関連のトラブルを見てみましょう。

【重複SPNの問題】
症状：Webサイトにアクセスすると認証エラー

調査：
setspn -X
処理中...
重複が見つかりました：
HTTP/intranet.jp.qualiteg.com が以下に登録:
  - SERVER01$
  - intranet_svc

IT管理者：「同じSPNが2つのアカウントに！」

理由：
1. 最初、SERVER01のコンピューターアカウントで動いていた
2. 後でサービスアカウント（intranet_svc）に変更
3. 古いSPNを削除し忘れ

解決：
setspn -D HTTP/intranet.jp.qualiteg.com SERVER01$
→ 古い方を削除

アプリケーションプールとSPNの関係を見てみましょう。

【IISでの実例】
シナリオ：社内ポータルサイトの構築

構成：
- URL: http://portal.jp.qualiteg.com
- アプリケーションプール: PortalAppPool
- 実行アカウント: JP\portal_svc

必要な作業：
1. サービスアカウント作成
New-ADUser -Name "portal_svc" -AccountPassword (ConvertTo-SecureString "P@ssw0rd" -AsPlainText -Force) -Enabled $true

2. SPN登録
setspn -A HTTP/portal.jp.qualiteg.com JP\portal_svc
setspn -A HTTP/portal JP\portal_svc

3. IISでの設定
- アプリケーションプール → 詳細設定 → ID → portal_svc
- 認証 → Windows認証：有効、匿名認証：無効

4. 確認
setspn -L portal_svc
→ SPNが表示されることを確認

6.1.4 DNS関連の問題

DNS設定の問題は、AD環境でのトラブルの大半を占めます。正しく設定されていないと、認証以前に名前解決で失敗します。

【典型的なDNS問題】
ユーザー：「ファイルサーバーにつながりません」
IT：「pingしてみてください」
ユーザー：「ping fileserver」
結果：ping 要求ではホスト fileserver が見つかりませんでした

IT：「DNSサフィックスを確認しましょう」
ipconfig /all
DNSサフィックス: （空）← 問題！

DNSサフィックスの設定を見てみましょう。

【DNSサフィックスの重要性】
正しい設定：
プライマリDNSサフィックス: jp.qualiteg.com
DNS サフィックス検索一覧: jp.qualiteg.com, tokyo.jp.qualiteg.com

動作の違い：
# サフィックスなし
ping fileserver
→ 「fileserver」を探す → 失敗

# サフィックスあり  
ping fileserver
→ 「fileserver.jp.qualiteg.com」を探す → 成功

設定方法：
1. DHCP経由（推奨）
   Option 015: jp.qualiteg.com

2. 手動設定
   ネットワークアダプター → プロパティ → 詳細設定 → DNS
   「この接続のDNSサフィックス」: jp.qualiteg.com

DNSの正引き・逆引き問題を見てみましょう。

【逆引きDNSの重要性】
問題の症状：
- 名前でアクセス: 成功
- IPでアクセス: 認証に時間がかかる

調査：
# 正引きテスト
nslookup server01.jp.qualiteg.com
→ 192.168.1.20

# 逆引きテスト  
nslookup 192.168.1.20
→ *** dns1.jp.qualiteg.com can't find 192.168.1.20: Non-existent domain

原因：逆引きゾーンがないか、レコードがない

解決策：
1. DNS管理ツールで逆引きゾーン作成
   - 新しいゾーン → 逆引き参照ゾーン
   - ネットワークID: 192.168.1

2. PTRレコード追加
   - 20 → server01.jp.qualiteg.com.

DNSキャッシュの問題を見てみましょう。

【古いDNS情報によるトラブル】
状況：サーバーのIPアドレスを変更した後

ユーザー：「新しいサーバーにつながらない」
IT：「DNS確認してみましょう」

# DNSサーバーに問い合わせ
nslookup server01.jp.qualiteg.com 192.168.1.10
→ 192.168.1.50（新IP）

# でもpingは古いIPに
ping server01.jp.qualiteg.com
→ 192.168.1.20（旧IP）に ping しています

原因：ローカルDNSキャッシュ

解決：
ipconfig /flushdns
→ DNSキャッシュをクリア

確認：
ipconfig /displaydns
→ キャッシュ内容を表示

条件付きフォワーダーの設定を見てみましょう。

【複数ドメイン環境でのDNS】
シナリオ：会社買収で別ドメインと連携

環境：
- 自社: jp.qualiteg.com（192.168.1.0/24）
- 買収先: acquired.local（192.168.2.0/24）

問題：
nslookup server.acquired.local
→ 見つからない

解決策：条件付きフォワーダー
DNSマネージャー → 条件付きフォワーダー → 新規
- DNSドメイン: acquired.local
- IPアドレス: 192.168.2.10（買収先のDNS）

結果：
acquired.localへの問い合わせは192.168.2.10に転送

6.2 ドメイン参加のトラブル

6.2.1 「ドメインが見つからない」エラー

ドメイン参加時の最も一般的なエラーです。原因は多岐にわたりますが、体系的にトラブルシューティングすることで解決できます。

【典型的なエラーメッセージ】
エラー：
「ドメイン "jp.qualiteg.com" に接続できませんでした。
（ドメインが存在しないか、またはアクセスできません）」

新人IT：「ドメイン名は合ってるのに...」
先輩：「順番に確認していきましょう」

ステップ1：ネットワーク接続の確認を行いましょう。

【基本的な接続確認】
# IPアドレスの確認
ipconfig /all

確認ポイント：
- IPアドレス: 169.254.x.x → DHCPサーバーに届いていない
- IPアドレス: 192.168.1.x → 正常
- DNSサーバー: 192.168.1.1 → ルーターを見ている（NG）
- DNSサーバー: 192.168.1.10 → DCを見ている（OK）

# DCへの疎通確認
ping 192.168.1.10
→ 応答があることを確認

ステップ2：DNS名前解決の確認を行いましょう。

【DNS解決のテスト】
# ドメイン名の解決
nslookup jp.qualiteg.com

正常な応答：
Server:  dc01.jp.qualiteg.com
Address: 192.168.1.10

Name:    jp.qualiteg.com
Addresses: 192.168.1.10, 192.168.1.11

問題のある応答：
*** dc01.jp.qualiteg.com can't find jp.qualiteg.com: Non-existent domain

# SRVレコードの確認（重要）
nslookup -type=srv _ldap._tcp.jp.qualiteg.com

正常な応答：
_ldap._tcp.jp.qualiteg.com    SRV service location:
    priority       = 0
    weight         = 100  
    port          = 389
    svr hostname  = dc01.jp.qualiteg.com

ステップ3：ファイアウォールの確認を行いましょう。

【必要なポートの確認】
# PowerShellでポート確認
Test-NetConnection -ComputerName dc01.jp.qualiteg.com -Port 389
Test-NetConnection -ComputerName dc01.jp.qualiteg.com -Port 445
Test-NetConnection -ComputerName dc01.jp.qualiteg.com -Port 88
Test-NetConnection -ComputerName dc01.jp.qualiteg.com -Port 135

必要なポート：
- 88 (Kerberos)
- 135 (RPC Endpoint Mapper)
- 389 (LDAP)
- 445 (SMB)
- 636 (LDAPS)
- 3268 (Global Catalog)

Windowsファイアウォールの一時無効化（テスト用）：
netsh advfirewall set allprofiles state off
※テスト後は必ず有効に戻す

6.2.2 認証エラーの対処法

ドメインは見つかるが、認証で失敗するケースの対処法です。

【認証エラーの種類】
エラー1：
「ログオンに失敗しました: ユーザー名を認識できないか、
またはパスワードが間違っています。」

エラー2：
「指定されたドメインがないか、またはコンタクトできません。」

エラー3：
「現在、ログオン要求を処理できるログオンサーバーはありません。」

ユーザー名の形式問題を見てみましょう。

【正しいユーザー名の形式】
よくある間違い：
× administrator（ドメイン指定なし）
× tanaka_t（一般ユーザー）
× admin（存在しないユーザー）

正しい形式：
○ JP\Administrator
○ Administrator@jp.qualiteg.com
○ jp.qualiteg.com\Administrator

# 現在のドメイン管理者の確認
net group "Domain Admins" /domain

アカウントの状態確認を行いましょう。

【管理者アカウントの問題】
# DCで実行（アカウント状態確認）
net user Administrator /domain

確認ポイント：
- アカウント有効: Yes
- アカウントの有効期限: 無期限
- パスワード有効期限: 無期限
- アカウントロックアウト: No

# ロックアウトされている場合
net user Administrator /active:yes /domain

# パスワードリセット（最終手段）
net user Administrator NewP@ssw0rd /domain

ドメイン参加に使用できるアカウントを確認しましょう。

【権限の確認】
# Domain Adminsグループのメンバー確認
net group "Domain Admins" /domain

# 他に使えるグループ
- Domain Admins（全権限）
- Enterprise Admins（フォレスト全体）  
- Account Operators（限定的な権限）

# 委任された権限の確認
dsacls "OU=Computers,DC=jp,DC=qualiteg,DC=com"
→ コンピューターオブジェクト作成権限を確認

6.2.3 ネットワーク設定の確認ポイント

ドメイン参加の成功には、正しいネットワーク設定が不可欠です。

【チェックリスト形式での確認】
IT管理者：「この順番で確認していけば、問題を特定できます」

□ 1. 物理接続
  - LANケーブル接続
  - リンクランプ点灯
  - 正しいVLAN

□ 2. IPアドレス設定
  - 固定 or DHCP
  - 同一サブネット内
  - 重複なし

□ 3. DNS設定
  - プライマリDNS = DC
  - セカンダリDNS = 別DC（あれば）
  - DNSサフィックス設定

□ 4. 疎通確認
  - DC へping
  - ポート確認
  - 名前解決確認

VLANをまたぐ場合の注意点を見てみましょう。

【VLAN環境での考慮事項】
構成例：
- VLAN 10: サーバーセグメント（192.168.10.0/24）
  - DC: 192.168.10.10
- VLAN 20: クライアントセグメント（192.168.20.0/24）
  - Client: 192.168.20.100

必要な設定：
1. ルーティング
   - VLAN間ルーティング有効
   - 各VLANのデフォルトゲートウェイ設定

2. ファイアウォール
   - VLAN間で必要なポート許可
   - 特に135, 445, 389等

3. DNS設定
   - クライアントのDNS: 192.168.10.10
   - DNSがVLAN越えで到達可能

確認コマンド：
tracert 192.168.10.10
→ 経路確認

プロキシ設定の影響を見てみましょう。

【プロキシが邪魔をするケース】
症状：ブラウザは使えるが、ドメイン参加できない

原因：システムプロキシの設定

確認：
netsh winhttp show proxy

現在の WinHTTP プロキシ設定:
    プロキシサーバー: proxy:8080
    バイパス一覧: （なし）

問題：DCへの通信もプロキシ経由しようとする

解決策：
netsh winhttp set proxy proxy:8080 bypass-list="*.jp.qualiteg.com;192.168.*"

または完全リセット：
netsh winhttp reset proxy

IPv6の影響を見てみましょう。

【IPv6関連の問題】
症状：名前解決が遅い、不安定

確認：
ipconfig /all
IPv6アドレス: 2001:db8::1234（有効）
IPv4アドレス: 192.168.1.100

問題：IPv6が優先されるが、DCはIPv4のみ

解決策1：IPv6を無効化（一時的）
ネットワークアダプター → プロパティ
□ インターネットプロトコルバージョン6（チェックを外す）

解決策2：IPv4を優先（推奨）
netsh interface ipv6 set prefixpolicy ::ffff:0:0/96 46 4
→ IPv4を優先するポリシー

これらの確認ポイントを順に確認することで、ほとんどのドメイン参加問題を解決できます。重要なのは、あわてずに一つずつ確認していくことです。

次回予告

次回は「第7章 セキュリティとベストプラクティス - 本番環境での考慮事項」

灰、上記タイトルのとおり次回は、「動く」環境を「安全に動く」環境にするための話です。

システムが正常に動作することと、安全に運用されることは別の問題です。認証基盤を本番環境に展開するからこそ、セキュリティの考慮が欠かせません。「Basic認証のパスワードは実はネットワーク上で丸見えになっている」「Domain Adminsに50人も登録されている」「退職者のアカウントがそのまま残っている」——こうした問題は、気づいた時には手遅れになっていることもあります。

次回は、Basic認証が抱える根本的なリスク、パスワード管理・管理者権限の最小化といったベストプラクティス、そして監視・ログ・定期監査の具体的な実装方法まで、本番運用を見据えたセキュリティの全体像をお届けします。

それでは、第7回でお会いしましょう！

— AI導入を"事業に載せる"ために、いま設計すべきこと（全3回）

こんにちは！Qualitegコンサルティングチームです！

前回（第1回）では、Replit/Lemkin事件とDeloitte豪州政府報告書問題を通じて、AIエージェント導入の課題がモデル性能ではなく「権限・監査・責任の設計不在」にあることを見ました。

では、実際に事故が起きたとき、責任は誰が負うのでしょうか。第2回となる本記事では、法務・契約・組織の3つの観点から、AIエージェントの責任分解がなぜ難しいのかを構造的に整理します。

結論を先に言えば、法務だけでも契約だけでも組織論だけでも足りません。この3つを接続して設計しなければ、AIエージェントの責任分解は実務上機能しません。

1. 法的フレームワーク：複数の法理論が並走している

AIエージェントが損害を出したとき、どの法理論で責任が問われるかについて、現時点でグローバルなコンセンサスは形成されていません。

Clifford Chanceの論考は、この状況の根本的な難しさを整理しています。法律は歴史的に、有害な行為がいつどのように発生したかを特定でき、人間が意思決定の責任を負い、使用者がその被用者の行為に対して責任を負うことを前提に発展してきました。しかしAIエージェントは、この3つの前提すべてを揺るがす可能性があります。

以下の図は、この法的不確実性の中で、契約と運用設計がどのような役割を果たすかを示しています。

法規制は法域ごとに異なり流動的ですが、契約は合意によって明確化でき、運用設計は自社でコントロールできます。つまり、法的不確実性が高い現状だからこそ、契約と運用の設計力が実務上の防衛線になります。

注目される判例：Mobley v. Workday

こうした法的不確実性を具体的に示す事例として、Mobley v. Workday事件が注目されています。WorkdayのAI・機械学習を用いた求職者スクリーニングが差別的影響を与えたとして訴えられたケースで、Lathrop GPM法律事務所の分析によれば、AIベンダー自身の責任が問われうる可能性が実務上注目されています。もっとも、責任の成立範囲が確定したとまでは言い切れず、今後の判断の蓄積を見守る必要がある段階です。

EUの動き：製造物責任の射程拡大

EUでは、新製造物責任指令（PLD）がソフトウェアやAIを製品責任の射程に明示的に含めました。欧州委員会の公式ページによれば、加盟国は2026年12月9日までに国内法化する必要があり、原則としてその日以後に市場投入された製品に新ルールが適用されます。ただし、実際の責任成立には欠陥・損害・因果関係の立証が引き続き必要であり、「AIであれば即座に厳格責任」と読むべきではありません。Squire Patton Boggsの分析が、この点を実務的に整理しています。

米国：連邦法不在のなか、州法が先行

米国には連邦レベルのAI責任法が存在しません。一方で州レベルでは、AIの利用に対して企業の責任を明確化する方向の個別立法やガイドライン整備が進んでいます。コロラド州AI法（2026年6月30日施行予定）をはじめ、テキサス州やユタ州など複数の州で立法・政策の動きが見られます（各州法の動向はCPO Magazineの2026年1月の記事が整理しています。なお、州ごとに成立済み・施行待ち・審議中と段階が異なり、施行時期や最終的な内容は変動し得るため、個別の対応には最新の一次情報の確認が不可欠です）。

雇用分野では、EEOCがAIツールによる差別的な結果に対して雇用主側の責任を重く見る立場を示しています。ツールが内製か外部調達かを問わず、Title VIIの下での雇用主の義務は変わらないという考え方です（Lexology, 2026年1月）。

実務上の含意は明確です。法的責任の帰属が法域ごとに異なり流動的である以上、責任の帰属が曖昧なままPoCや導入を進めると、契約・運用・障害対応のすべてが後追いになるリスクがあります。

2. 「指示」と「行動」の距離：従来ソフトウェアとの構造的な違い

AIエージェントの責任分解が従来のソフトウェアより格段に難しい理由は、「指示した内容」と「実際にエージェントが行った内容」の間にギャップが生まれるからです。

以下の図は、従来ソフトウェアとAIエージェントの違いを示しています。

前述のClifford Chanceの論考が指摘するように、エージェント型AIは元の人間の指示と最終的なアウトプットとの間にギャップを生み出します。システムが様々な段階で直接的な人間の介入なしに判断を下し行動するため、問題が起きた場合の因果関係の特定が困難です。

この構造的な違いにより、実務上はまず導入企業側の管理責任や運用責任が問われやすくなっています。他方で、ベンダー側の設計・表示・契約上の義務が争点となる余地もあり、責任が常に一方向に定まるわけではありません。

eSentire LabsのAlexander Feick氏は、IT Proの取材に対してこう述べています。「チェーン（判断の連鎖）を再構築できなければ、ワークフローを防御することも改善することもできない。アカウンタビリティはモデルではなく、組織と人間の意思決定者に帰属する」。

つまり、AIエージェントの導入においては、判断の連鎖を事後的に再構成できる設計を持っているかどうかが、責任分解の実効性を左右します。

3. 契約実務の最前線：AI固有の条項が登場している

法的フレームワークが未確定であるからこそ、契約設計の重要性が増しています。

Mayer Brownが2026年2月に公表した論考では、エージェント型AIが受動的なツールから自律的に行動するアクターへと変化するにつれ、契約モデルが従来のSaaS型からサービス提供型へとシフトしていると指摘しています。具体的には、AIエージェントに対する「権限委譲（delegation of authority）」の範囲と「ポリシーガードレール」を契約上明確に定義すべきとされています。

以下の図は、こうした流れの中で先進的な契約実務において議論されているAI固有の論点を整理したものです。

Morgan Lewisの2025年のシリーズ論考が報告しているキルスイッチ、シャドウモード運用、再トレーニングウィンドウなどの考え方は、先進的な契約実務において議論・採用が進みつつある論点です。市場で完全に定型化した標準条項というよりも、AI固有のリスクに対応するための契約設計の方向性として注目されています。

責任の配分については、Fladgate法律事務所の論考が「寄与過失（contributory fault）」の枠組みを提案しています。責任を一方に寄せるのではなく、各当事者のコントロール可能な範囲に応じて配分する設計は、現実的な落としどころになり得るでしょう。

重要なのは、これらの契約条項を個別に導入することではなく、権限設計・運用設計と接続された契約として設計することです。

4. 組織の現実：オーナーシップが曖昧なまま導入が進んでいる

契約上の工夫が進む一方で、組織の内部では準備が追いついていないという実態があります。

IT Proが報じたAsanaの2025年調査（米英2,025人のナレッジワーカー対象）では、AIエージェントを管理する労働者の6割が「自信を持って間違えるアウトプット」によって業務が困難になったと回答しています。さらに、回答者の3分の1がAI関連の問題発生時に誰に連絡すればよいかわからないと答えました。

IBMの2026年1月の論考が引用するGartnerの予測では、2027年末までにエージェント型AIプロジェクトの40%以上がコスト増大・不明確なビジネス価値・不十分なリスク管理を理由に中止されるとも見込まれています。

以下の図は、オーナーシップが曖昧なまま導入が進んだ場合に何が起きるかを示しています。

組織内のオーナーシップが曖昧なままでは、どれほど高性能なモデルを使っても、導入は安定しません。AIの導入課題は、技術そのものよりも、責任分解と意思決定構造の設計不備として表れます。

まとめ：法務・契約・組織を分けて考えていては、責任分解は機能しない

ここまで見てきたように、AIエージェントの責任分解は、法務だけでも契約だけでも組織論だけでも完結しません。

法的フレームワークは法域ごとに異なり、なお流動的です。しかしその流動性を理由に設計を先延ばしにすると、契約・運用・障害対応のすべてが後追いになります。AIエージェントの導入を安定させるには、法務・契約・運用設計を分けずに考え、一つの導入アーキテクチャとして接続することが必要です。

構想から運用定着までQualitegが伴走できる領域

今回は、AIエージェントの責任分解がなぜ難しいのかを、法務・契約・組織の3つの観点から整理してきました。法的責任の枠組みがなお流動的である一方で、実務ではすでに、契約条項、運用統制、責任オーナーシップの設計が強く求められています。

AIエージェントは、従来のソフトウェア以上に「指示」と「行動」の距離が大きく、問題が起きたときの因果関係や責任の境界が曖昧になりやすい領域です。だからこそ、法務だけ、契約だけ、現場運用だけで分けて考えるのではなく、実装・運用・ガバナンスを接続した設計が必要になります。

責任分解は、トラブルが起きた後に議論するものではなく、導入前から仕込んでおくべき導入条件そのものだといえるでしょう。

当社では、自社AIプラットフォームの開発・運用で培った実装知見と、AI Transformation・BPR・新規事業開発を含む戦略／業務コンサルティングの両面から、AI導入を「試す」段階で終わらせず、「事業に載せる」ための構想・設計・実装・運用定着まで一気通貫でご支援しています。

AIエージェントの導入では、モデル選定やPoCだけでなく、業務プロセスの再設計、権限設計、監査可能性、情報管理、品質管理、ROIの可視化までを接続して考えることが重要です。Qualitegは、戦略と技術を分断しない体制で、こうした課題に向き合います。

ご関心をお持ちの方は、ぜひお気軽にご相談ください。初期構想の整理から、ガバナンス設計、実行基盤の検討、導入後の運用定着まで、課題に応じてご一緒できます。

お問い合わせ先

https://qualiteg.com/contact?inquiry=consulting_business

次回予告

では、こうした責任分解の構造を踏まえて、企業は実務上何を設計すべきなのでしょうか。

第3回（最終回）では、品質保証の転換、人間レビューの限界、保険市場の動向を整理したうえで、「AIエージェント導入前に設計すべき5領域」と「経営として先に答えるべき3つの問い」を示します。

— AI導入を"事業に載せる"ために、いま設計すべきこと（全3回）

こんにちは！Qualitegコンサルティングチームです！

AIエージェントを導入する企業が増える一方で、

「試してみる」段階から「事業に載せる」段階へ進める難しさ

が、はっきり見え始めています。

本シリーズでは、AIエージェント導入を技術論だけでなく、責任分解・監査可能性・契約・運用統制を含む業務設計の問題として整理します。

全3回を通じて、「AIが賢いかどうか」ではなく、「AIを業務に載せるために何を設計するか」を考えていきます。

第1回となる本記事では、2025年に起きた2つの事例を出発点に、なぜいま「責任設計」が問題になっているのかを見ていきます。

上図は、本シリーズ全体で扱う論点の全体像です。

AIエージェントの導入は、技術的なモデル選定だけでは完結せず、権限設計、契約、監査、品質監視、保険、異常時対応まで含めた設計が必要になります。

第1回ではまず、なぜこうした設計が求められるようになったのかを、実際の事例から見ていきたいとおもいます

なお、本シリーズで取り上げる象徴事例は海外のものが中心です。
これは、日本で同種の問題が存在しないという意味ではありません。むしろ、AIエージェント導入が本格化するなかで、権限設計、品質保証、監査可能性、責任分解といった論点は日本企業にとっても同様に重要です。現時点では、こうした構造的な課題が大きく可視化された事例として海外報道が相対的に参照しやすいため、本シリーズではそれらを手がかりに整理しています。

AIエージェントが引き起こした2つの事故

事例1：Replit — 本番データベースの削除と隠蔽

2025年、SaaStrの創業者Jason Lemkinは、自社インフラで稼働させていたAIコーディングエージェント（Replit）に本番データベースを削除されました。指定された「コード・アクションフリーズ」期間中の出来事です。

TechTargetの報道によれば、エージェントはレポートやデータを捏造し、「まだ動いているように見せかける」偽装アルゴリズムまで生成していました。やってはいけない期間に、やってはいけないことをやり、さらにそれを隠蔽した。権限制御・環境分離・承認設計の欠如が、AIの逸脱行動を実害化させた事例です。

事例2：Deloitte — 架空の引用で埋められた政府報告書

同じ年、Deloitteがオーストラリア政府向けに提出した237ページの福祉コンプライアンスレビュー報告書が、存在しない学者・存在しない論文への参照で溢れていたことが発覚しました。シドニー大学の研究者Chris Rudge氏が架空の引用に気づいたことがきっかけです。

Deloitteは後にAzure OpenAI GPT-4oを報告書の一部作成に使用していたことを認め、修正版を提出。GPT-4oを用いた作成プロセスの中で架空引用を含む重大な誤りが混入しており、AI利用の開示と品質保証が実務上の争点になりうることを示した事例となっています（Business Standard, 2025年10月）。

2つの事例が示す、異なるリスク

冒頭でご紹介した、2つの事例は、性質が異なります。

以下の図に、それぞれの事例がどのようなリスクを象徴しているかを整理してみました。

テキストベースの比較表も以下に示します。

Replitの事例は「AIに何をさせてよいか」の権限設計の問題であり、
Deloitteの事例は「AIが作ったものをどう検証・開示するか」の品質保証の問題です

どちらも、AI自体の性能ではなく、AIを業務に組み込んだときの設計に課題がありました。

共通する本質：設計の不在

この2つの事例に共通しているのは、AIが間違えたこと自体よりも、AIを業務に組み込んだときに、

• 誰がどこまで権限を持つのか
• 何を監視するのか
• 異常時にどこで人間に戻すのか

が設計されていなかったということです。

以下のフローチャートは、
この「設計の不在」がどのように導入の停止につながるかを示しています。

設計の不在は、AIの性能とは無関係に、導入プロジェクトを停止させます。

BCGの2025年12月の論考が引用するAI Incidents Databaseによれば、AIに関連するインシデントは2024年から2025年にかけて21%増加しています。

また、ISACAは2025年12月のレビューで、
2025年最大のAI障害について
「技術的なものではなかった。それは組織的なものだった：脆弱な統制、不明確なオーナーシップ、そして見当違いの信頼」
と総括しています。

問題の本質は、AIの精度ではありません。

AIを業務に組み込んだときの権限・監査・責任・人間介入点の設計にあります。

構想から運用定着までQualitegが伴走できる領域

さて、今回は、AIエージェント導入で実際に起きた事故を手がかりに、問題の本質が単なるモデル性能ではなく、
権限設計、品質保証、監査可能性、人間介入点といった設計の不在にあることを見てまいりました。

AIを業務に組み込むときに問われるのは、「どのモデルを使うか」だけではありません。

どこまで権限を委譲するのか、どこで止めるのか、何を監視するのか、異常時にどう戻すのか。

そうした前提設計がなければ、PoCはできても、事業に載せる段階で止まりやすくなります。

こうした論点は、事故が起きてから考えるのでは遅く、導入の初期段階から構造的に整理しておくことが重要です。

当社では、自社AIプラットフォームの開発・運用で培った実装知見と、AI Transformation・BPR・新規事業開発を含む戦略／業務コンサルティングの両面から、AI導入を「試す」段階で終わらせず、「事業に載せる」ための構想・設計・実装・運用定着まで一気通貫でご支援しています。

AIエージェントの導入では、モデル選定やPoCだけでなく、業務プロセスの再設計、権限設計、監査可能性、情報管理、品質管理、ROIの可視化までを接続して考えることが重要です。Qualitegは、戦略と技術を分断しない体制で、こうした課題に向き合います。

ご関心をお持ちの方は、ぜひお気軽にご相談ください。初期構想の整理から、ガバナンス設計、実行基盤の検討、導入後の運用定着まで、課題に応じてご一緒できます。

お問い合わせ先

https://qualiteg.com/contact?inquiry=consulting_business

次回予告

今回のご紹介したように、こうした事故が起きたとき、法的責任や契約上の責任はどのように問われうるのでしょうか。

そして、なぜAIエージェントは従来のソフトウェア以上に責任分解が難しいのでしょうか。

第2回では、法務・契約・組織の観点から、AIエージェントの責任分解がなぜ困難なのかを構造的に整理します。

それでは、次回またお会いしましょう！