Claudeの使い方を決める4つの判断軸。選ぶ・読ませる・任せる・効かせる

Claudeを業務で使い始めたものの、モデルの種類が増え、機能の名前も増えて、何をどこまで使えばいいのか整理できていないという方も多いでしょう。

ただ、機能を一つひとつ覚えても「自社のどの業務にどれを当てるか」は決まりません。判断に必要なのは機能の一覧ではなく、判断の物差しのほうです。

そこで本記事では、Claudeの使い方を

・選ぶ（どのモデルを当てるか）

・読ませる（どの資料をどう渡すか）

・任せる（どこまで自動化するか）

・効かせる（組織の成果に変えるか）

という4つの判断軸に分けて解説します。社内でAI活用を推進する立場の方は、ぜひ最後までご覧ください。

自社の業務にClaudeをどう組み込むか整理したいという方はリベルクラフトへご相談ください。

⇨リベルクラフトへの無料相談はこちら

Claudeの使い方でつまずくのは、機能を覚えられないからではない

Claudeとは、Anthropic社が開発している対話型のAIサービスです。ブラウザやデスクトップアプリから使えるほか、APIやAmazon Bedrockなどのクラウド経由でも利用できます。

そのClaudeについて、弊社に届く相談で最も多いのは「使えていない」ではありません。「使ってはいるが、体系立っていない」です。

「とりあえず使っている」から抜け出せない理由

現場でよく見かけるのは、次のような状態です。

• 各自が思い思いにチャット画面を開き、思いついたことを聞いている
• モデルは最初に選ばれていたものから変えたことがない
• うまくいった聞き方は個人のメモに残っているだけで、共有されていない
• 「機密情報は入れないように」とは言われているが、線引きは各自の判断

この状態が続く理由は、情報が足りないからではありません。むしろ逆で、モデルの世代交代や新機能の発表が続き、情報が多すぎて整理が追いつかない状態です。

そしてもう一つ、追いかける対象を間違えているという問題があります。モデル名の枝番、たとえば4.6なのか4.8なのかといった数字は数か月で変わります。そこを追い続ける限り、いつまでも「最新に追いつく」ことが目的になってしまい、自社の業務の話に降りてきません。

追いかけるのは型番ではなく、4つの判断軸

持ち帰るべきは、Claudeというアプリの操作ノウハウではなく、自社で何をどこまで使うかを決めるための判断軸です。本記事では次の4つに分けます。

1. 選ぶ — モデルには段階がある。どの業務にどの段階を当てるか
2. 読ませる — どんな資料をどう渡すと、使える答えが返ってくるか
3. 任せる — チャットで答えさせる以上のこと、つまり作業そのものをどこまで渡せるか
4. 効かせる — 個人の便利で終わらせず、組織の成果に変えるために何を決めるか

この4つは、モデルが何世代進んでも構造が変わりません。型番が変わっても、当てはめ方の考え方は使い回せます。順番に見ていきます。

判断軸①選ぶ。Claudeのモデルを難しさとボリュームで使い分ける

最初の判断軸は「選ぶ」です。Claudeには性格の違うモデルが複数あり、どれを使うかでコストも品質も速度も変わります。

Claudeのモデルは4段の階層になっている

Claudeに限らず、各社のAIモデルは「速くて安いもの」から「賢いが高くて遅いもの」まで段階を分けて提供されています。この構造はOpenAIのGPTでも他社でも同じです。

Claudeの場合、2026年8月時点の現行モデルは次の4つです。

モデル	位置づけ	コンテキスト	最大出力	100万トークンあたり価格（入力・出力）	最安との比
Claude Haiku 4.5	最速・低コスト	20万トークン	6.4万トークン	入力1ドル・出力5ドル	1倍
Claude Sonnet 5	速度と知性のバランス	100万トークン	12.8万トークン	入力3ドル・出力15ドル	3倍
Claude Opus 5	複雑なエージェント型の作業・企業業務向け	100万トークン	12.8万トークン	入力5ドル・出力25ドル	5倍
Claude Fable 5	一般提供されている中で最高性能	100万トークン	12.8万トークン	入力10ドル・出力50ドル	10倍

出典：Anthropic「モデル概要」（https://platform.claude.com/docs/ja/about-claude/models/overview ・2026年8月5日確認）

いくつか補足します。

• 「最安との比」は、入力と出力の単価を足した合計で比べたものです。Haiku 4.5が合計6ドル、Sonnet 5が18ドル、Opus 5が30ドル、Fable 5が60ドルになります
• Claude Sonnet 5には2026年8月31日まで入力1ドル・出力5ドル引き下げた導入価格が適用されています。恒常的な単価ではないため、試算には表の標準価格を使うほうが安全です
• Claude Mythos 5という名前を見かけることがありますが、これはProject Glasswingという枠組みで防御的なサイバーセキュリティ向けに招待制で提供されているもので、一般提供はされていません。通常の業務検討の対象からは外して構いません

覚えておきたいのは、個々のモデル名ではなく4段の階層があるという構造です。

一番安いモデルと比べてコストは最大10倍変わる

前の表の右端に注目してください。最も安いHaiku 4.5を1とすると、Fable 5は10倍です。同じ処理を流しても、どのモデルを選ぶかだけで請求額が10倍変わります。

この差が効いてくるのは、単発のチャットではなく大量処理のときです。たとえば問い合わせメールを1万件分類する場合、Haikuで足りる仕事にOpusを当てていると、支払う金額が5倍になります。逆に、複雑な契約書の論点整理をHaikuに投げると、安いかわりに使いものにならない答えが返り、人が全部やり直すことになります。

つまり、どのモデルを当てるかは節約の話ではなく、業務の設計そのものです。

難しさとボリュームの2軸で当てるモデルを決める

では何を基準に選ぶのか。実務では「難しさ」と「ボリューム」の2軸で考えると整理できます。

• 難しさが低く、ボリュームが多い → Haiku。問い合わせの一次振り分け、タグ付け、定型的な要約など
• 難しさもボリュームも中程度 → Sonnet。日常の文書作成、議事録の整理、社内向けの調べもの
• 難しさが高く、量もある程度こなす → Opus。複雑な資料の読み解き、長時間かかる自走作業
• 難しさが最も高く、量は絞れる → Fable。頻繁に回すものではなく、他で解けなかった問題にだけ当てる

弊社が支援した現場でも、ITに詳しくない部門の担当者が「最初から選ばれていたモデルのまま」ずっと使い続けていた例がありました。悪気があるわけではなく、選べることを知らなかっただけです。使い分けを提案しただけで、体感の速度も月々のコストも改善しました。

判断軸を持つというのは、この「デフォルトのまま使い続ける」状態を抜けるということです。

同じモデルのままコストを下げる2つの方法

モデルを下げる以外にも、コストを下げる手段があります。APIで開発する場合の話になりますが、規模が大きくなるほど効きます。

1. 即時に答えが要らない処理はバッチに回す

Message Batches APIを使うと、大量のリクエストを非同期でまとめて処理でき、コストが50%削減されます。1つのバッチで最大10万件または256MBまで扱え、多くは1時間以内に完了します（最大24時間、結果は29日間取得可能）。

判断の手順はこうです。

1. その処理は、依頼した人がその場で答えを待っているか確認する
2. 待っていないなら（夜間の一括分類、過去データの棚卸し、大量の要約など）バッチに回す
3. 待っているなら（チャット応答、画面上の即時要約）通常のAPIのままにする

出典：Anthropic「バッチ処理」（https://platform.claude.com/docs/ja/build-with-claude/batch-processing ・2026年8月5日確認）

2. 共通の前提文はキャッシュを効かせる

同じ社内規程や同じ指示文を毎回送っているなら、プロンプトキャッシュが効きます。キャッシュから読み込んだ分の入力単価は通常の0.1倍、つまり9割引になります。書き込み時は5分保持で1.25倍、1時間保持で2.0倍のコストがかかるため、同じ前提を繰り返し使うほど得になる仕組みです。

出典：Anthropic「プロンプトキャッシング」（https://platform.claude.com/docs/ja/build-with-claude/prompt-caching ・2026年8月5日確認）

この2つを押さえておくと、「上位モデルは高いから使えない」という判断を早まらずに済みます。賢いモデルを要所で使いつつ、全体のコストは下げられます。

判断軸②読ませる。Claudeに資料の山をそのまま渡す使い方

当てるモデルが決まったら、次はそのモデルに何をどう渡すかです。ここが2つ目の判断軸「読ませる」になります。

読ませられる「量」と「種類」の両方が広がった

以前のAIは、一度に読ませられる情報量が少なく、扱えるのもテキストだけでした。そのため長い資料は人が切り分けて、順番に貼り付ける必要がありました。

現在は状況が変わっています。

• 量：Claude Sonnet 5、Opus 5、Fable 5はいずれも100万トークンのコンテキストを持ちます。Haiku 4.5は20万トークンで、軽量モデルはここでも差がつきます
• 種類：PDFであれば、中のテキストだけでなく画像・チャート・表も解釈の対象になります。1リクエストあたり32MB、600ページまで扱えます（コンテキストが100万トークン未満のモデルでは100ページ）

出典：Anthropic「PDFサポート」（https://platform.claude.com/docs/ja/build-with-claude/pdf-support ・2026年8月5日確認）

結果として、資料を小分けにして貼り付ける運用から、関係する資料をまとめて渡す運用へ移行できます。プロジェクトのフォルダに複数の資料を入れて、そこに対して質問するという使い方が現実的になりました。

効く業務は長文レビューと複数資料の突き合わせ

Claudeでできることを業務単位で整理すると、読ませる系で成果が出やすいのは次の2種類です。

長い文書から論点を引き出す仕事

• 契約書を読ませて、リスクになりうる条項と、その根拠ページを挙げさせる
• 稟議書を読ませて、決裁者が確認すべき論点を整理させる
• 会議の記録から、決定事項と担当者付きのToDoを抜き出させる

複数の資料を突き合わせる仕事

• 複数の社内規程を同時に読ませ、記述が食い違っている箇所を挙げさせる
• 旧版と新版の仕様書を渡し、変わった点と影響範囲を出させる
• 見積書と発注書と請求書を並べ、金額や条件の不一致を洗い出させる

人手では追いきれない量の突き合わせを一気通貫でやらせられる点が、以前との大きな違いです。出力を表形式で指定すれば、そのまま確認作業に使えます。

届かない領域もある。性能にはグラデーションがある

一方で、できないことも把握しておく必要があります。ここを曖昧にしたまま期待値だけ上げると、社内の信頼を一度で失います。

• 複雑な図面の精緻な読み取りは、汎用のClaudeでは届かないことが多いです。寸法や公差、記号の意味まで正確に拾う必要がある業務では、図面に特化したソリューションを別途作り込む判断になります
• 軽量モデルは扱える量も少ないです。Haiku 4.5は20万トークンなので、大量の資料をまとめて渡す用途には向きません
• 同じ「読める」でも精度に濃淡があります。文章中心のPDFは得意、表や図が入っていてもある程度は解釈できる、複雑な図面は苦手、という具合にグラデーションがあります

「何でも読めるはずなのに、なぜ図面が読めないのか」という反応をよく聞きますが、これは能力が一律ではないためです。得意な領域と苦手な領域があると理解しておくと、検証の設計を間違えずに済みます。

渡し方で結果が変わる。観点・形式・根拠を指定する

「プロンプトエンジニアリング」という言葉自体はあまり聞かなくなりましたが、渡し方が結果を左右する事実は変わっていません。曖昧な指示は、今のモデルでも浅い答えになります。

指定すべきは次の3点です。

• 観点：何を見てほしいのか（例：解約条件と損害賠償の上限）
• 形式：どんな形で返してほしいのか（例：条項番号・要旨・リスク度の3列の表）
• 根拠：どこに書いてあったかを示させるか（例：該当ページと引用文を併記）

具体例で比べます。

浅い答えになる渡し方

この契約書を確認してください。

使える答えになる渡し方

添付の契約書について、解約条件と損害賠償の上限の2つの観点でリスクになりうる条項を挙げてください。条項番号・要旨・リスク度（高中低）の3列の表にし、各行に根拠となるページ番号と引用文を添えてください。判断に迷う箇所は「要確認」として理由も書いてください。

やっていることは、業務の依頼を人に出すときと同じです。丸投げにしないという一点で、返ってくるものが変わります。この原則はモデルが世代交代しても変わりません。

ここまでClaudeに資料を読ませる使い方を解説しましたが、「社内の規程や契約書の山をAIに読ませて、論点や矛盾を洗い出したい。ただ、どこまで任せられるのか自社だけでは見極められない」という方は、リベルクラフトへご相談ください。

リベルクラフトでは、社内文書を対象にしたRAG（社内データを検索して回答に反映させる仕組み）の構築が可能です。ただ、仕組みを作るだけでなく、どの資料をどの粒度で渡し、どこから先は人が判断するかという線引きまで設計するため、実装前に費用と効果の見通しを立てられます。

以下のリンクからまずは詳細をチェックしてみてください。

⇨リベルクラフトへの無料相談はこちら

判断軸③任せる。ClaudeのAIエージェント機能で人の手を離す

読ませて答えさせるところまで来ました。次は、人が手を動かしている部分をどこまで渡せるかという話に進みます。3つ目の判断軸「任せる」です。

AIチャットとAIエージェントは別物

これまでのAIの使い方は、一問一答のチャットが中心でした。人が質問し、AIが答え、その答えを人が使う。作業そのものは人が行う形です。

2025年後半から2026年にかけて主流になったのは、長く自走するエージェント型の使い方です。ゴールと条件と制約を与えると、AIの側が次のループを自分で回します。

1. どう進めるかを計画する
2. 実行する
3. 結果をチェックする
4. うまくいっていなければやり直す

その過程で、Web検索、ファイルの読み書き、外部ツールの呼び出し、コードの実行といった手段を使い、最終的な成果物まで持っていきます。人がやることは、指示と最後の確認です。

「文章で答えるAI」から「手を動かして仕上げるAI」への変化と捉えると分かりやすいと思います。名前は今後も変わりますが、この仕組みの部分を理解しておけば追いかけられます。

Claude CodeとCoworkをどう使い分けるか

Claudeでエージェント的な使い方をする入口は、大きく2つあります。

Claude Codeはターミナル、つまりコマンドを打つ画面から使うタイプです。開発や自動化に強く、複数ファイルにまたがる作業を任せられます。ただし、どうしてもエンジニアリング寄りの前提知識が要ります。

Claude Coworkは非エンジニアの業務に向けたタイプです。ターミナルを使わず画面から操作でき、ファイル、カレンダー、メール、メッセージングアプリ、Web、そのほか接続したツールを横断して、仕事が終わるところまで進めます。2026年4月9日にすべての有料プランで一般提供が始まりました。

注目したいのは、Anthropicが公表しているCowork利用の90%超がソフトウェア開発以外だという点です。エンジニアのための道具ではなく、事務職や専門職の業務そのものが対象になっています。

出典：Anthropic「Claude Cowork」（https://claude.com/product/cowork ・2026年8月5日確認）

選び方はシンプルです。

• 対象業務にコードやリポジトリが絡む、あるいは推進担当がエンジニアなら Claude Code
• 対象がExcel・Word・PowerPointの処理、資料作成、調べもの、メールや予定の処理なら Cowork

どちらを選ぶにしても、この後に述べるスキルは共通の土台になります。まずどちら側かを決め、その上で両方で使えるスキルを作り込むのが現実的な進め方です。

属人化した業務は、AIを使ってもまた属人化する

ここが、組織で使う上で最も大事な点です。

各人がバラバラに指示を出していると、返ってくる出力もバラバラになります。うまい聞き方を見つけた人の手元だけで品質が上がり、その人がいないと再現できません。つまり、属人化している業務は、AIを使ってもまた属人化し続けます。

営業担当が10人いれば、提案書のたたき台が10人10色になる。これは以前と何も変わっていません。ツールを入れただけでは、属人化は解消されないどころか、AIという新しい形で温存されます。

目指すのは逆の状態です。営業担当が10人いても、同じ手順と同じ判断基準で、同じ水準の出力が出る。そのために必要なのが、次に述べるスキルの共有です。

スキルを共有して組織の型にする

Claudeには、やってほしいことの手順をパッケージ化してAIに持たせるスキル（Agent Skills）という仕組みがあります。

スキルは`SKILL.md`というファイルを中心にしたフォルダです。中には手順書のほか、参照ドキュメント、テンプレート、実行するスクリプトなども置けます。特徴は、スキルの本体が使われるときにだけ読み込まれる点です。長い参照資料を持たせても、必要になるまでコストがほとんどかかりません。

出典：Anthropic「スキルで Claude を拡張する」（https://code.claude.com/docs/ja/skills ・2026年8月5日確認）

スキル化の手順は次の通りです。

1. すでに誰かがうまくやっている業務を1つ選ぶ（推進担当が選定）。ゼロから設計せず、社内で再現したい手本があるものから始めます
2. その人のやり方を言語化する（本人＋推進担当）。どういう順番で作業するか、何を見て判断するか、どのデータを参照するか、出力はどんな形式かを書き出します
3. `SKILL.md`に落とす（推進担当）。手順・判断基準・参照先・出力フォーマットを1ファイルにまとめます。本文は簡潔に保ち、長い資料は別ファイルに分けて参照させます
4. チームで共有する（推進担当＋情シス）。プロジェクトの`.claude/skills/`をバージョン管理にコミットすればチーム全員が使えます。組織全体に配りたい場合は管理設定から配布します
5. 使われ方を見て直す（四半期ごと）。想定と違う使われ方をしていたら、説明文や判断基準を書き直します

この形になると、社内には議事録の整理スキル、契約書の一次レビュースキル、定型メールの作成スキルといった資産が溜まっていきます。個人のプロンプト職人芸に頼っていた状態から、組織の型に変わります。

エージェントが効きやすい業務の4条件

とはいえ、何でもエージェントに任せられるわけではありません。最初の1件を選ぶときは、次の4条件でふるいにかけると外しにくくなります。

1. 手順がある程度決まっているが、一手間かかる — 完全な定型作業ならRPAで足ります。判断が少し混じるものが向いています
2. 頻度が多い — 月1回の作業を自動化しても効果が見えません。日次・週次で回っているものを選びます
3. 失敗しても致命傷にならない — まずは社内向けの業務から。対外的な確定文書や金額の確定処理は後回しにします
4. 最終確認・承認を人がする状態にできる — 出力をそのまま外に出さず、人が見る工程を残せるかどうか

この4条件を満たす業務は、どの会社にもいくつかあります。定例レポートの作成、問い合わせの一次振り分け、会議記録からのToDo抽出、月次資料の下書きなどが典型です。

なお、定期実行と組み合わせると効果が上がります。毎日決まった時刻に情報を集め、レポートにまとめ、共有フォルダに置くところまで自動で回し、人は結果を確認するだけにする、という運用です。

判断軸④効かせる。Claudeの使い方を組織の成果に変える

任せる仕組みまで分かりました。ただ、個人や一部門で回せても、組織全体では止まります。最後の判断軸「効かせる」です。

個人利用は進んだのに、組織で詰まっている

この状況は、感覚ではなく統計にも表れています。総務省が2026年7月24日に公表した令和8年版情報通信白書によると、日本の状況は次の通りです。

指標	日本	米国	ドイツ	中国
個人の生成AI利用経験率	58.8%（前年26.7%）	75.6%	75.6%	93.6%
何らかの業務で生成AIを利用している企業	86.4%（前年55.2%）	90.9%	91.6%	98.1%
業務変革に向けた「組織的な取組はない」	27.0%	1.4%	4.9%	2.6%

出典：総務省「令和8年版 情報通信白書」（https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r08/html/datashu.html ・2026年8月5日確認）

読み取れることは3つあります。

• 使うかどうかの議論はほぼ終わった。個人の利用経験率は1年で2倍以上、企業の業務利用も86.4%まで来ており、米国やドイツとの差は縮まりました
• 一方で、組織的な取組は決定的に遅れている。「組織的な取組はない」と答えた企業が日本では27.0%あり、米国の1.4%と比べて桁が違います。個人が触ることと、業務が変わることの間に大きな段差があります
• 効果の期待も偏っている。日本企業が期待する効果は「作業時間の短縮などによる業務効率化」が61.6%と突出し、製品やサービスの質の向上は32.2%にとどまります

ここを越えるかどうかは、モデルの性能ではなく業務設計の問題です。導入したが使われていないという状態については、社内AIが使われない理由と定着させる方法でも整理しています。

ハルシネーションは起きる前提で設計する

組織で使うと決めた瞬間に必要になるのが、間違えたときの扱いです。

AIが事実と異なる内容を自信ありげに出す現象は、モデルが進化しても無くなりません。エージェント型になろうが、上位モデルに変えようが同じです。精度が100%になる前提で運用を組むと、最初のトラブルで利用が止まります。

混じりやすいのは次の領域です。

• 情報の引用（出典や条文番号の取り違え）
• 計算（桁や集計の誤り）
• 最新情報（学習時点より後の事実）
• 社内情報の引用（参照先が渡されていない場合の推測）

打ち手は2つあります。1つは参照させるデータを設計することです。社内文書を検索して回答に反映させる仕組みを作れば、推測ではなく根拠から答えさせられます。もう1つはスキルを詳細化することです。どのデータを見るか、何を根拠として示すかまでスキルに書いておくと、出力のばらつきが減ります。

その上で、任せる範囲と人が判断する範囲を線引きします。エージェント的に動かすほどリスクの高い業務にもAIが入り込むため、どこまでを自動で通し、どこから人が承認するかを決めておく必要があります。

法人契約では入力データが学習に使われない

経営層から最も多く聞かれるのが、入れたデータがどう扱われるかです。

Anthropicの方針では、法人向け製品（Claude for WorkやAnthropic APIなど）の入力・出力は、デフォルトではモデルの学習に使用されません。例外は、フィードバックボタンで明示的に報告した場合など、利用者が許可した場合です。

出典：Anthropic「Is my data used for model training?」（https://privacy.claude.com/en/articles/7996868-is-my-data-used-for-model-training ・2026年8月5日確認）

一方、個人向けのプランは扱いが異なります。ここから導かれる実務上の判断はシンプルです。

• 業務で使うなら法人契約に寄せる。個人アカウントの持ち込み利用を放置しない
• どのデータをどこまで入れてよいか、社内の線引きを文書にする。「機密情報は入れない」だけでは各自の解釈に委ねられます

入力してよいデータの分類の仕方は、生成AIの利用ルールの作り方にまとめています。

データを国内で完結させる構成も作れる

情報を国外に出せないという制約がある場合でも、選択肢はあります。

Amazon Bedrock経由でClaudeを使う場合、日本国内クロスリージョン推論という仕組みを利用できます。推論リクエストは東京（ap-northeast-1）または大阪（ap-northeast-3）にルーティングされ、推論処理が国内で完結し、データが国外に出ません。通信は暗号化され、AWSのネットワーク内に留まります。

出典：AWS「Amazon Bedrock で日本国内クロスリージョン推論がサポートされました」（https://aws.amazon.com/jp/blogs/news/amazon-bedrock-now-supports-japan-cross-region-inference/ ・2026年8月5日確認）

判断としては、次の3段階で考えると整理できます。

1. 通常の業務データ → 法人契約のClaudeをそのまま使う
2. 国外に出せない制約がある → Amazon Bedrockの国内完結構成を検討する
3. 外部サービスに出すこと自体が認められない → 自社環境で動かすローカルLLMを検討する

3番目の判断基準については、ローカルLLMの構築ガイドで詳しく解説しています。

Claudeの使い方を自社に落とし込む4つのステップ

4つの判断軸が揃いました。最後に、明日から動くための順番に落とします。

ステップ1：繰り返し業務を1つ選ぶ（担当：推進担当、期間：1週間）

先に挙げた4条件（手順が決まっている・頻度が多い・失敗が致命傷にならない・最終確認は人）でふるいにかけ、候補を3つに絞ってから1つ選びます。同時に、その業務で現在かかっている時間を測っておきます。後で効果を説明する材料になります。

終わった判断基準：対象業務が1つに決まり、現状の所要時間が数字で出ている。

ステップ2：人の確認を挟んでエージェントに移す（担当：現場担当と推進担当、期間：2〜4週間）

いきなり自動で完結させず、AIが作った成果物を人が確認する形で回します。この段階でモデルも決めます。難しさとボリュームの2軸で当て、コストが気になるならバッチやキャッシュを検討します。

終わった判断基準：人の手戻りが許容範囲に収まり、所要時間が導入前より短くなっている。

ステップ3：スキル化して手順と判断基準を固定する（担当：推進担当、期間：1〜2週間）

うまくいった進め方を`SKILL.md`に落とします。手順・判断基準・参照データ・出力フォーマットまで書き、プロジェクトのスキルとしてバージョン管理にコミットします。ここを飛ばすと、担当者が異動した時点で元に戻ります。

終わった判断基準：本人以外が同じスキルを使って、同水準の出力を出せている。

ステップ4：多部門へ広げ、モデルとコストを見直す（担当：推進部門と情シス、期間：四半期ごと）

同じ型が使える業務を他部門から探して展開します。あわせて、利用量が増えた分のモデル配分とコストを見直します。最初はSonnetで組んだ処理が、実は大半はHaikuで足りるといったことがよくあります。

終わった判断基準：2部門以上で同じスキルが動いており、コストの実績値が把握できている。

この4ステップが回り始めたら、次は全体像を3年程度の計画に広げる段階に入ります。

まとめ

本記事のポイントを整理します。

• Claudeの使い方でつまずく原因は情報不足ではなく、追いかける対象が型番になっていること。持つべきは判断軸
• 選ぶ：モデルは4段の階層。最安のHaiku 4.5を1とするとSonnet 5が3倍、Opus 5が5倍、Fable 5が10倍。難しさとボリュームの2軸で当てる
• 即時の応答が要らない処理はバッチAPIで50%削減、共通の前提文はプロンプトキャッシュで入力単価が0.1倍になる
• 読ませる：現行の主要モデルは100万トークンのコンテキストを持ち、PDFの表や図も解釈できる。ただし複雑な図面は届かず、性能にはグラデーションがある
• 渡し方では観点・形式・根拠の3点を指定する。丸投げにしないという原則はモデルが変わっても同じ
• 任せる：チャットとエージェントは別物。開発寄りならClaude Code、非エンジニアの業務ならCowork。Cowork利用の90%超はソフトウェア開発以外
• 属人化している業務はAIを使ってもまた属人化する。スキルとして手順・判断基準・出力形式を共有して初めて組織の型になる
• エージェントが効くのは、手順が決まり・頻度が多く・失敗が致命傷にならず・最終確認を人がする業務
• 効かせる：日本企業の業務利用は86.4%まで来た一方、「組織的な取組はない」が27.0%（米国1.4%）。段差は業務設計にある
• ハルシネーションは起きる前提で、参照データの設計とスキルの詳細化で抑える。法人契約なら入力データはデフォルトで学習に使われず、国内完結の構成も選べる

ウェビナー資料（ホワイトペーパー）のダウンロード

本記事の内容は、ウェビナー「最新Claudeは何ができるようになったか（2026年版総点検）」をもとに再構成したものです。当日使用した資料では、モデル階層の地図、難しさ×ボリュームの使い分けマトリクス、Claude CodeとCoworkの対比、エージェント導入の進め方を、そのまま自社の検討に持ち込める形でまとめています。

⇨ウェビナー資料のダウンロードはこちら

Claude活用・AI導入の相談は「リベルクラフト」

判断軸が分かっても、自社のどの業務に当てはめ、どこまで任せ、どう組織に広げるかは、業務とデータの実態を見ないと決まりません。一般的なフレームワークだけでは、自社の候補のどれが実現できてどれが難しいのかまでは判断できないためです。

リベルクラフトでは、業務課題の棚卸しとユースケースの優先順位づけから、PoCの設計・実装、本番運用、社内への定着支援までを一貫して支援しています。社内データを検索して回答に反映させるRAGの構築や、機密データを外に出せない環境でのローカルLLM構築といった実装面も、同じチームで対応できます。

• Claudeを部分的には使えているが、どの業務にどのモデルを当てるべきか判断しきれない
• 個人利用は広がったものの、組織としての標準が定まらず出力がばらついている
• 社内文書をAIに読ませたいが、機密情報の扱いと構成の選択肢を整理したい

⇨リベルクラフトへの無料相談はこちら