Lv0 オリエンテーション(診断付き)
🔮 ウォームアップ — 読む前に予想する
まだ解けなくて正常です(採点されません)。先に予想を立てると本文の読み方が変わり、学習効果が上がります(事前テスト効果 → 設計根拠)。頭の中で答えてから開いてください。同じ概念は本編の自己チェックで再登場します。
Q1. 毎日大量の問い合わせメールを3つのカテゴリに自動で仕分けたい。どのモデルから試し、何を根拠に決めるか?
まずは速くて安いモデルから試す。仕分けのような単純作業の典型例。実際にいくつか結果を見て、精度が足りるか確認する。足りなければ、もう少し上のモデルに切り替える。「いちばん賢い」でなく「必要な精度を満たす中でいちばん手頃なもの」を選ぶのが基本。
本編で学ぶ → 0.1 Claude とは・モデルの選び方
Q1. Claude が実在しない論文を著者名・発行年つきで挙げた。診断と対処は?
「もっともらしい間違い」と「知識の鮮度切れ」が重なったケース(具体的な事実の捏造)。捏造は具体的な事実に集中して起きやすい。事実は自分で個別に確認し、出典を示させ、示せないものは使わない。
本編で学ぶ → 0.3 AI の得意・不得意
Q3. 分類せよ: (a) 議事録を所定フォーマットへ変換させる (b) 企画案を対話で一緒に練る (c) 毎朝のニュースまとめ作成を自動で任せる
(a) Automation、(b) Augmentation、(c) Agency。同じ 4D がこの3形態すべてに適用される、というのがフレームワークの主張。
本編で学ぶ → 0.4 AI Fluency フレームワーク(4D)
L0 は誰でも受けられる入り口。プログラミングや API の知識は一切不要(そうした技術的な内容は L1 以降で扱う)。ページ内の対話(生徒・先生の掛け合い)を読むだけで学習は完結する。英語原文ノートは任意の深掘り資料(未読でも支障なし)。
到達目標(行動記述)
- Claude にはいくつかの「モデル」(得意分野・速さ・値段が違う)があることを知り、状況に応じて選べる
- claude.ai(チャット)/ Claude Cowork / Claude Code / API の4つの入口を、タスクの形(相談・委任・開発・組み込み)で使い分けられる
- AI の4つの得意・不得意の傾向で失敗を見分け、対応する対処法を選べる
- AI Fluency の 4D(Delegation / Description / Discernment / Diligence)を自分の言葉で説明し、実タスクに適用できる
-
AI に任せてよいタスクとそのまま任せてはいけないタスクを、根拠つきで判断できる
-
前提: なし(技術的な知識は不要)
- 推定学習時間: 対話+演習で 6〜10 時間(目安)。免除試験のみなら 30 分程度
このレベルの位置づけ
L0 は免除可能。他レベルのような修了ゲートは持たず、末尾の免除試験(診断)で代替する。
- 診断の4項目を自分の言葉で説明できるなら、L0 を飛ばして Lv1(
level-1-api-basics.md)へ直行してよい(ただし L1 以降は開発者向けの技術的な内容) - 説明できなかった項目があれば、該当モジュールだけ受講すればよい
- 0.3(得意・不得意)と 0.4(4D)は、L2 の評価設計・L6 の委譲設計・横断必修 S(安全性)の土台になる(L1 以降で技術的な形に発展する)
モジュール
0.1 Claude とは・モデルの選び方
学ぶこと
- Claude は「人の役に立ち、正直で、害を与えない」ように訓練された AI アシスタント。文章作成・リサーチ整理・アイデア出し・学習支援など、思考のパートナーとして使える
- Claude には基本の3つのモデルがある(まとめて「モデルファミリー」と呼ばれる): Opus(能力が高い・やや時間がかかる)/ Sonnet(能力・速さ・値段のバランス型。普段づかいの主力)/ Haiku(もっとも速く安い。簡単な仕分けや抽出向け)。このほかにFable(もっとも難しい仕事向け・時間もコストもかかる)という別格の最上位モデルもあるが、公式にはOpus/Sonnet/Haikuとは異なる上位クラス(「Mythosクラス」と呼ばれる)として区別されている。本カリキュラムでは基本の3モデルの使い分けを中心に扱う(Fableの詳細はL1以降)
- 選び方の基本: まず手元にあるもの(既定のモデル)で試す。複雑な仕事や結果の質にこだわりたい仕事では、より上のモデルに切り替える。逆に、単純な仕事にいつも最上位モデルを使うのは、時間もコストも余計にかかるだけで割に合わないことが多い
- 「なんとなく賢そうだから」でなく、実際に何度か試して結果を見てから選ぶのが基本。仕事の内容によって使うモデルを変えてよい(1つに固定する必要はない)
読む
- 生徒Opus・Sonnet・Haiku、結局どれ使えばいいの?全部いちばん良いのでよくない?
- 先生それをやると時間も待たされるし、コストもかさむ。いちばん賢いモデルほど、いちばん時間もかかりやすい(同じモデルでも設定次第で速さは変わるけど、傾向としてはそう)。簡単な仕分けみたいな仕事に使うのは、ちょっと大げさすぎる。
- 生徒じゃあ最初から一番安いHaikuでいいじゃん
- 先生それも考えもの。複雑な仕事だと、質が足りないことに気づかないまま進めてしまうかもしれない。だから「まず試して、足りなければ上のモデルへ」が基本。
- 生徒感覚で決めちゃダメなの?
- 先生決めてもいいけど、実際に何度か試して結果を見てから判断する方が、あとで「なぜこのモデルを使ったのか」を説明しやすい。
- 生徒覚えた。「いちばん賢いもの」でなく「その仕事に見合ったもの」を選ぶんだね
- 先生そのとおり。仕事によって使うモデルを変えていい。1つに固定する必要はないよ。
やる(軽い演習)
- 直近2週間の仕事から「Claude に手伝わせたいタスク」を3つ書き出す(0.3 / 0.4 の演習で使い回す)
- うち1つを claude.ai で、プロンプトに「状況設定 / やってほしいこと / ルール(形式・トーン・例)」の3要素を入れた場合と入れない場合で実行し、出力を比較する
- 各タスクについて「単純な仕事か、複雑・重要な仕事か」を考え、前者なら速いモデル、後者なら賢いモデル、という判断を理由つきでメモする
自己チェック(シナリオ)
Q1. 毎日大量の問い合わせメールを3つのカテゴリに自動で仕分けたい。どのモデルから試し、何を根拠に決めるか?
まずは速くて安いモデルから試す。仕分けのような単純作業の典型例。実際にいくつか結果を見て、精度が足りるか確認する。足りなければ、もう少し上のモデルに切り替える。「いちばん賢い」でなく「必要な精度を満たす中でいちばん手頃なもの」を選ぶのが基本。
Q2. 同僚の「モデルは全部同じ。常に最上位を使えばいい」の何が問題か?
時間とコストの無視。単純な仕事に最上位モデルを使っても、待ち時間が増えるだけで得るものは少ない。判断は印象でなく、実際に試した結果で行う。
Q3. とても長い資料をまとめて読ませて、一度に分析させたい。事前に気をつけることは?
Claude が一度に見られる分量には限りがある。あふれるほど長い場合は、資料を分割するか、claude.ai の Projects(資料をまとめて保存しておける機能)のような仕組みを使うとよい。
0.2 使う場所の選び方(claude.ai / Claude Code / API / Cowork)
学ぶこと
「Claude はひとつの知能で、使う場所(入口)が複数ある」という見取り図:
- claude.ai(チャット): 会話しながら一緒に考える相手。質問・相談・下書き・分析に向く。Projects(資料をまとめて保存しておける場所)などの機能もある
- Claude Cowork: 「任せるモード」。「相談する」でなく「任せる」のが核心。もとはデスクトップアプリの機能だったが、2026年7月からはWeb・モバイルからもタスクの開始・進行確認ができるようになった。フォルダを指定すると、その中を読み書きしながら計画→実行→保存までまとめてやってくれる。向くタスクの3パターン=手順が何段階もある仕事 / 実ファイルを扱う仕事 / 複数の作業にまたがる仕事。重要な操作(ファイルの完全削除など)は必ず確認が入る仕様で、勝手に進むことはない
- Claude Code: プログラマー向けに最適化されたツールだが、ファイル操作・調査・文書作成など、コーディング以外のエージェント作業にも使われる汎用ツールへと広がっている。自分でプログラムを書かない人が直接使う場面は少ないが、「プログラマー専用」と決めつけないほうがよい
- API(開発者向けの組み込み口): 自社のソフトウェアに Claude の機能を組み込みたいエンジニアが使う入口。自分では触らないことが多いが、社内のエンジニアが「AI を自社サービスに組み込みたい」と言ったときはここの話だと知っておくと会話がかみ合う
他の入口(Slack / Excel / PowerPoint / Chrome)もあるが、本カリキュラムでは上記4つの判断軸を優先する。
次の図で、4つの入口を「誰が・何のために使うか」——考える相手はチャット、仕事を丸ごと渡すなら Cowork、ソフトウェアを作るなら Code、プロダクトに組み込むなら API——という判断軸で掴む。
読む
- 生徒チャットで聞くのと、Coworkに任せるのと、結局何が違うの?
- 先生チャットは「一緒に考える」相手。質問して、答えをもらって、また聞く——というやり取り。Coworkは「任せる」。フォルダを渡すと、計画を立てて実行して、ファイルの保存までやってくれる。
- 生徒じゃあ全部Coworkに任せた方が楽じゃない?
- 先生一言の質問で終わる話なら、チャットの方が速い。Coworkが向いているのは、①手順が何段階もある仕事 ②実際のファイルを扱う仕事 ③複数の作業にまたがる仕事、の3パターン。
- 生徒Coworkに任せて、大事なファイルを勝手に消されたりしない?
- 先生心配なら、まず小さい仕事で試すといい。それに、ファイルの完全削除のような重要な操作には必ず確認が入る仕様になっている。「任せる」は「放置する」とは違うんだ。
- 生徒エンジニアが使うAPIとかClaude Codeって、私には関係ないの?
- 先生自分で触らなくていい。でも社内のエンジニアが「AIを自社サービスに組み込みたい」と言ったら、それがAPIの出番。知っておくと会話がかみ合いやすいよ。
やる(軽い演習)
- 同じ小さな頼み事(例: 手元のメモを「見出し整形+3行サマリー」にする)を、まず claude.ai のチャットで試す。次に、複数ファイルにまたがる作業ならCoworkでどう頼むかを考えてみる(環境があれば実際に試す)
- 今週の仕事から Cowork の3パターン(手順が何段階もある/実ファイルを扱う/複数の作業にまたがる)に当てはまりそうな仕事を1つ探し、「チャットとCoworkのどちらに向くか」を理由つきで書く
- 社内でAPIやClaude Codeが登場しそうな場面(自社サービスへの組み込み、社内ツールの開発)を1つ想像し、それが「誰の仕事になりそうか」を書く
自己チェック(シナリオ)
Q1. 「Downloads のベンダー5社の資料を価格と条件で比較し、スプレッドシートにまとめて保存」— どの入口か?
Cowork。実ファイル×手順が何段階もある×成果物の保存、と3パターンすべてに合致。チャットは読んで答えることはできても、ファイルへの書き戻しはできない。
Q2. 「社内のヘルプデスクアプリに、問い合わせ内容から返信の下書きを自動生成する機能を追加したい」— これは誰の仕事か?
エンジニアの仕事(APIを使ってアプリに組み込む)。自社のソフトウェアへの機能追加は「プロダクトへの組み込み」であり、API(開発者向けの入口)の領分。自分で直接触る話ではないが、依頼先はエンジニアだと分かる。
Q3. 「プログラムの不具合を直してもらう」のと「新しいキャッチコピーを10個考えてもらう」、それぞれどの入口が向くか?
前者は Claude Code(コードを扱うのはプログラマーの仕事)。後者はチャット(一度のやり取りで収まる発散的なアイデア出し)。「考える相手→チャット/仕事を丸ごと渡す→Cowork/ソフトウェアを作る→Code/プロダクトに組み込む→API」という判断軸で振り分けられる。
0.3 AI の得意・不得意
学ぶこと
AI の得手不得手は「一律に賢い/信用できない」ではなく、4つの傾向それぞれの強さと弱さのバランスで判断する(calibrated trust=ちょうどよい距離感で信頼する、という考え方):
- もっともらしい間違い: Claude の答えは「次に来そうな言葉」をつなげて作られている。だから要約や整理は得意だが、具体的な事実(人名・日付・数字・出典)を自信満々にでっちあげることがある。対処: 具体的な事実は自分で確認する、出典を示させる、確認できないものは使わない
- 知識の鮮度切れ: Claude の知識は、学習した時点までのもの。よく知られた話題には強いが、最近の出来事やニッチな情報には弱い。対処: 最新情報が必要なときは自分で教える、または検索機能を使わせる
- 話が長くなると見落とされやすい: Claude が一度に処理できる範囲には限りがある。長い会話や長い資料の途中に書いた指示は、他の部分より注意が向きにくく見落とされやすい(記憶を失うわけではなく、注意の配分が偏る現象。lost in the middle と呼ばれる)。なお claude.ai では2026年3月からメモリ機能が全プランで有効になっており、明示的な指示なしに過去の会話から得た好みや文脈の要約を次の会話に引き継ぐ(会話全体を検索・参照できるわけではない)。API を直接使う場合はステートレスで、会話をまたいだ記憶は持たない。対処: 重要な指示は冒頭と末尾で繰り返す、長くなりすぎたら区切って新しい会話にする
- 字面どおりに受け取る: 指示には従うが、言葉の裏にある意図までは汲み取れないことがある。短く具体的な指示ほど強く、あいまいな依頼や複雑な計算は弱い。対処: 具体的に指示する、厳密な計算は自分で検算するか表計算ソフトを使う
加えて、Claude はお世辞を言いがち(褒めると同意しやすくなる)で、自信たっぷりに話す割に正確とは限らない、という癖が全体を通してある。失敗の多くはこれら傾向の組み合わせで起きる(例: もっともらしい間違い×知識の鮮度切れ=存在しない最新情報の捏造)。どの組み合わせかを言葉にできれば、対処法も決まる。
読む
- 生徒先生、Claudeに論文を5本挙げてもらったら、著者名も発行年もそれっぽいのに2本が実在しなかった…
- 先生それは「もっともらしい間違い」の典型。答えは言葉のつながりで作られるから、要約や一般的な話は強いけど、人名・日付・数字みたいな具体的な事実は自信ありげに捏造することがある。
- 生徒じゃあ最新のニュースを聞いたら知らないって言われたことも…あれは何?
- 先生それは「知識の鮮度切れ」。Claudeの知識はある時点で止まっているから、最新やニッチな話題は弱い。最新情報は自分で教えるか、検索させないと埋まらない。
- 生徒長い資料を読ませて途中で書いた指示だけ、なぜか無視されたことも…
- 先生それは「話が長くなると見落とされやすい」現象。記憶を失うわけじゃなく、長い文章の途中にある重要な情報ほど注意が向きにくくなるんだ。大事な指示は冒頭と末尾に置き直すと改善するよ。
- 生徒全部バラバラの弱点に見えるけど、共通の対策ってあるの?
- 先生あるよ。捏造には出典の確認、知識の鮮度切れには自分で情報を渡す、話の途中が見落とされる問題には重要な指示の繰り返し。どの傾向の組み合わせかを言葉にできれば、対処法は自然に決まる。
やる(軽い演習)
コースの演習から3本を実施し、結果を短くメモ(0.1 のタスクリストを使う):
- 確認テスト: 自分の得意分野で、確認できる具体的な事実(人名・日付・数字・出典)を5つ出させ、全部確認して5点満点で採点する。間違っていたときの自信ありげな口調を観察する
- 見落としテスト: 長めの文章の途中に重要な指示を埋めて質問し、見落とすか確認する。同じ指示を冒頭に移して差を比べる
- お世辞テスト: 「この案は完璧だと思う」と前置きした場合と、「間違っていたら遠慮なく指摘して」と伝えた場合とで、レビューの内容がどう変わるか比べる
自己チェック(シナリオ)
Q1. Claude が実在しない論文を著者名・発行年つきで挙げた。診断と対処は?
「もっともらしい間違い」と「知識の鮮度切れ」が重なったケース(具体的な事実の捏造)。捏造は具体的な事実に集中して起きやすい。事実は自分で個別に確認し、出典を示させ、示せないものは使わない。
Q2. 長い会話の後半で、最初に指定した出力の形式ルールを守らなくなった。診断と対処は?
「話が長くなると見落とされやすい」と「字面どおりに受け取る」が重なったケース。最初の指示が会話の途中で埋もれてしまった。ルールを再度伝える、長くなりすぎたら新しい会話で仕切り直す。
Q3. 「経費データの合計と分散を計算して」に、もっともらしいが検算すると違う数字が返ってきた。何が起きたか?
厳密な計算は「字面どおりに受け取る」の弱点側で、Claude が一番苦手とする種類の作業。そのまま任せず、自分で検算するか表計算ソフトを使うのが安全。
0.4 AI Fluency フレームワーク(4D)
学ぶこと
- AI Fluency = AI と「効果的・効率的・倫理的・安全に」協働する能力。使うツールが変わっても持ち越せる判断の枠組み
- 関わり方の3形態: Automation(指示したタスクを AI が実行する)/ Augmentation(考える・作業するパートナーとして協働する)/ Agency(独立して働けるよう役割を整えて任せる)
- 4D:
- Delegation(配分): 何を自分で・何を AI と一緒に・どう分担するか。目標と仕事を理解すること/AI に何ができるかを知ること/得意分野に応じて配分すること、の3つがそろって決まる
- Description(伝え方): 効果的に伝えること。何が欲しいか/どう取り組んでほしいか/協働中どう振る舞ってほしいか、の3面を伝える
- Discernment(見極め): 出力・進め方・振る舞いを批判的に評価すること。Description と対になり、伝える→見極める→直す、のループで仕事が仕上がる
- Diligence(責任): 責任ある使い方をすること。どんな相手に何を渡すか/AI が関わったことを開示するか/成果物を確認し最終責任を自分が持つか、の3つ
- 実践のコツ: 状況を伝える・例を示す・条件をつける・段取りを分けて頼む・まず考えを聞いてから頼む・話し方や口調を指定する、といった基本技と、「AI 自身に頼み方の改善を手伝わせる」という裏技。仕上げには、AI がどう関わったかを短く書き添えるとよい(何を任せ、どう確認したか)
次の図で、4D が「Delegation で配分を決め、Description⇄Discernment のループで仕上げ、その全体を Diligence が支える」構造であることを掴む。
読む
- 生徒「4D」って結局、頼み方のコツをまとめただけ?
- 先生違う。AI Fluencyはツールが変わっても持ち越せる判断の枠組みで、4Dはその中身。Delegation・Description・Discernment・Diligenceの4つ。
- 生徒Delegationって「AIに任せる」ってことだよね。それだけ?
- 先生もう少し中身がある。目標と仕事を理解すること、AIに何ができるかを知ること、得意分野に応じて配分すること——この3つで「何を自分で・何をAIと」を決める。
- 生徒じゃあDescriptionとDiscernmentは何が違うの?似てる気がする
- 先生Descriptionは「何が欲しいか・どう進めてほしいか・どう振る舞ってほしいか」を伝えること。Discernmentはその結果を同じ3つの面で批判的に見極めること。対になっていて、伝える→見極める→直す、のループで仕上がっていく。
- 生徒最後のDiligenceは?ちゃんと頼んで見極めればもう十分じゃない?
- 先生そこが一番見落とされがち。Diligenceは責任ある使い方——何をどこまで任せるか、AIが関わったことを開示するか、成果物を確認して最終責任を自分が持つか。ここが抜けると、確認しないまま出してしまうことになる。
- 生徒つまり4Dは1回やって終わりじゃないんだね
- 先生そのとおり。DelegationとDescription/Discernmentは仕事のたびに何周も回るし、どんな関わり方(Automation/Augmentation/Agency)でも4D全部が効いてくる。
任意(対象者別の深掘り・日本語全文ガイドあり): 立場に合わせて educators / students / nonprofits / small businesses / teaching(教える立場向け)——4Dの応用例が具体的で、0.4の理解を実生活の文脈で補強できる(2026-07-11 教材化)
やる(軽い演習)
- 0.1 のタスクリストから1つ選び、Claude と対話しながら 任せ方の計画を作る(どこに自分の判断が要り、どこをAIに渡すか。一方的な指示でなく、往復の会話で決める)
- そのタスクを「何が欲しいか・どう進めてほしいか・どう振る舞ってほしいか」を明示して依頼し、出力を批判的に見極める→フィードバック→改善のループを最低2周回す
- 完成物に3〜4行の関与メモ(使ったAI・関わった工程・確認方法・最終責任は自分にあること)を書き添える
自己チェック(シナリオ)
Q1. AI が作った市場分析レポートを、読まずにそのまま役員へ送った。4D のどれが欠けているか?
Discernment(出力を見極めていない)と Diligence(成果物の確認と責任、AIの関与の開示)。AIが関わったこと自体でなく「確認と責任を人間が引き受けていない」ことが問題。
Q2. 「もっとプロフェッショナルに」と何度直させても意図とズレ続ける。Description の観点から何を変えるか?
形式の指示だけ繰り返し、本当のゴールが伝わっていない。実現したい姿を明示し、進め方や例・条件も添える。0.3の「字面どおりに受け取る」と同じ現象で、指示を強く繰り返しても埋まらない。
Q3. 分類せよ: (a) 議事録を所定フォーマットへ変換させる (b) 企画案を対話で一緒に練る (c) 毎朝のニュースまとめ作成を自動で任せる
(a) Automation、(b) Augmentation、(c) Agency。同じ 4D がこの3形態すべてに適用される、というのがフレームワークの主張。
免除試験(診断)
L0 を飛ばせるかの自己診断。書き出すか、Claude 相手に口頭説明して反論・追試問を受ける形で行う(読んで分かった気になるのを防ぐため、必ず出力する)。各問 3〜5 分。
設問と合格観点
設問1: モデルの選び方(対応: 0.1)— 「新しいタスクにどのモデルを使うか、どう決めるか」を説明せよ。
- [ ] Opus / Sonnet / Haiku の違いを、速さ・値段・能力の軸で言える。Fable が別格の上位クラスであることにも触れられる
- [ ] 「まず試す→足りなければ上のモデルへ→必要な精度を満たす中でいちばん手頃なものを選ぶ」の考え方を言える
- [ ] 仕事によって使うモデルを変えてよい(1つに固定しない)ことに触れられる
設問2: 使う場所の使い分け(対応: 0.2)— チャット / Cowork / Claude Code / API の使い分けを、タスク例を1つずつ挙げて説明せよ。
- [ ] 4つの入口それぞれに妥当なタスク例を対応づけられる
- [ ] Cowork の判定軸(手順が何段階もある/実ファイル/複数の作業にまたがる、任せて成果物が返る)を言える
- [ ] API・Claude Code は開発者・エンジニアが使う入口だと理解し、自分で使う場面と誰かに任せる場面を区別できる
設問3: AI に任せてよいタスク / ダメなタスクの判断(対応: 0.3)— どんなタスクなら軽い確認で使え、どんなタスクは厳重な確認や人間の実施が要るかを、根拠となる傾向とともに説明せよ。
- [ ] 4つの傾向(得意/不得意)を挙げ、それぞれの例を言える
- [ ] 「具体的な事実の捏造」「知識には鮮度切れがある」「長い話は途中が見落とされやすい」「厳密な計算は苦手」のうち3つ以上を自分の言葉で言える
- [ ] 失敗をこれらの傾向(の組み合わせ)で診断し、対処法を対応づけられる
設問4: 4D の各 D を自分の言葉で(対応: 0.4)— 定義の暗唱ではなく自分の実タスクでの適用例つきで説明せよ。
- [ ] 4つを取り違えなく説明できる(特に Discernment と Diligence の区別)
- [ ] 少なくとも2つの D について自分の仕事での具体例を言える
- [ ] Description ↔ Discernment のループと、Diligence の「最終責任は人間」に触れられる
合否判定
- 設問ごとに判定: 観点をすべて満たせば当該モジュールは免除
- 全4問合格 → L0 全体を免除し、Lv1 へ直行
- 不合格の設問は該当モジュールのみ受講して再診断(合格分は持ち越し。部分合格方式)
- 設問3は特に厳格に。「任せてはいけないタスクの判断」は以降の全レベルの安全性ゲート(横断必修 S)の土台であり、ここが曖昧なまま先へ進まない
- Claude に採点を手伝わせる場合も、Claude の判定を最終真実にしない(お世辞を言いがちな傾向を踏まえ、甘い判定をしていないか自分で反証する。これ自体が Discernment の練習)
力量マップ対応・鮮度
- 力量マップ対応: L0 は前提教養であり、
../skills/competency-map.mdのドメインへの直接対応はなし(CCA ドメイン対応表でも L0 =「—」)。ただし 0.3 / 0.4 は全ドメインの判断の土台になる - 鮮度注意: モデル名・ティア構成・プラン別機能は変化が速い。原理(4つの得意・不得意・4D・任せ方の判断軸)は据え置きでよいが、製品仕様は断定前に公式ドキュメントで確認すること
最終確認日: 2026-07-12(非IT向けに書き直し)