2026年9月、今使う価値がある生成AIツール──仕事別の選び方と、明日から動かす10のコード

2026年9月19日 06:00

生成AIの比較記事を読むと、モデル名と点数がずらりと並びます。しかし、会社で本当に困るのは「どれが一番賢いか」ではありません。議事録、調査、見積もり、資料作成、開発、画像制作。これらを誰が、何分で、どの品質まで終わらせるかです。

2026年9月の変化は、AIが回答する道具から、資料を読み、外部ツールを使い、成果物を完成させる道具へ進んだことです。AnthropicはClaude Fable 5.1をコーディングと知識労働向けとして説明し、OpenAIはGPT-6 Astraを難しい一連の仕事を終えるモデルと位置づけています。GoogleもGemini 3.8 Flashを推論、コーディング、エージェント用途へ広げています。ただし、宣伝文句が似ていても、価格、速さ、操作性、データの扱いは同じではありません。

この記事は2026年9月19日時点の公式情報を確認し、提供された2本の調査資料を実務向けに再編集したものです。製品の説明と、筆者による導入手順の提案を分けて記します。筆者が全製品を同じ条件で実機比較したという話ではありません。読者自身が小さく試し、数字で選べるように、10の仕事と10本の短いコードへ落とし込みます。

コードはPython 3.10以降の標準ライブラリだけで動く、独立した実例です。AIモデルを直接呼び出すコードではなく、選定・入力整備・検収を支える道具として使います。各コードを記載のファイル名でUTF-8保存し、codesフォルダの一つ上で実行してください。環境によってpythonをpython3またはpyに読み替えます。サンプルの企業名、評価点、時間、費用は架空例で、実在企業の成果ではありません。

1．最初にやるのは、ツール探しではなく仕事の棚卸し

生成AIの導入が止まる会社には、よくある順番の間違いがあります。先に有名なサービスを契約し、その後で使い道を探すのです。これでは、社員は空欄のチャット画面を前に「何を聞けばいいのか」と迷います。

先に仕事を並べましょう。最低限、業務名、月の回数、1回の所要時間、入力データ、最終成果物、間違えたときの影響を書きます。たとえば「問い合わせメールを担当部署へ振り分ける」は高頻度で、正解も判定しやすい。一方、「契約書を自動承認する」は間違いの影響が大きく、最初の自動化には向きません。同じ契約書でも「条項を抽出し、人が確認する一覧を作る」なら候補になります。

優先順位は、効果だけで決めません。「効果×頻度」に、実装のしやすさを足し、事故の影響を引くと、議論が具体的になります。点数は科学的な真理ではなく、関係者の認識をそろえるための物差しです。営業と管理部で評価が割れたら、それ自体が重要な発見です。

帝国データバンクの2026年3月調査では、回答企業1万312社の34.5％が生成AIを業務で活用し、活用企業の86.7％が効果を実感しています。活用率は大企業46.5％、中小企業32.4％、小規模企業28.0％でした。ただし、これは企業の自己申告であり、導入すれば同じ成果が出るという因果関係の証明ではありません。自社では何分減り、確認に何分かかったかを測る必要があります。調査概要と定義：帝国データバンク

実行コード01｜業務棚卸しの優先度

目的: AI化候補を感覚で選ばず、効果・頻度・実装容易性・リスクで並べます。

前提: 各項目は1〜5点。重みは自社の事情に合わせて変更してください。

変更箇所: tasks に候補業務を追加し、score() の式で評価軸の重みを調整します。

実行方法: python codes/01_work_inventory_priority.py

期待結果: 問い合わせ分類が1位になり、3業務が点数順に表示されます。

"""業務棚卸しを、効果・頻度・実装容易性・リスクから優先順位付けする。"""
tasks = [
    {"name": "週報の要約", "impact": 3, "frequency": 5, "ease": 5, "risk": 1},
    {"name": "契約書の自動承認", "impact": 5, "frequency": 2, "ease": 2, "risk": 5},
    {"name": "問い合わせ分類", "impact": 5, "frequency": 5, "ease": 4, "risk": 2},
]

def score(task):
    return task["impact"] * task["frequency"] + task["ease"] * 2 - task["risk"] * 3

ranked = sorted(((score(t), t["name"]) for t in tasks), reverse=True)
for rank, (points, name) in enumerate(ranked, 1):
    print(f"{rank}位: {name}（{points}点）")

ツールの比較も同様です。候補Aに自由質問をし、候補Bには別の難問を与えても比較になりません。同じ入力、同じ制限時間、同じ出力形式で試します。採点項目は、正確さ、修正にかかった時間、操作の分かりやすさ、根拠の追いやすさ、費用で十分です。

選ぶ基準は「最高点のAI」ではなく、「その仕事の合格線を、最小の総費用で安定して超えるAI」です。総費用には月額料金だけでなく、確認、手直し、教育、失敗時の復旧も含めます。この考え方を持つと、派手な新製品が出るたびに全社の道具を入れ替える必要がなくなります。

2．汎用モデルは、同じ課題を同じ採点表で比べる

汎用モデルの候補として、Claude Fable 5.1、GPT-6 Astra、Gemini 3.8 Flashが目立ちます。公式説明を見る限り、Fable 5.1は長時間のコーディングと知識作業、Astraは難しいエンドツーエンドの仕事、Gemini 3.8 Flashは推論、コーディング、エージェント処理と速度・単価の両立を強く意識しています。

ここから「Fableは文章、Astraは推論、Geminiは安さ」と固定するのは早計です。実務の品質は、モデルだけでなく、与える資料、指示、使えるツール、出力形式、確認工程で変わります。同じモデルでも、チャット画面とAPIでは設定や上限が違います。月額プランとAPI従量課金も別の商品です。

比較用の課題は、自社の仕事から三つ選びます。例として、①5ページの会議資料を300字に要約する、②問い合わせ文を5分類し理由を付ける、③売上表から異常値候補を挙げる、です。正解例を人が先に作り、会社名や個人情報を架空データへ置き換えます。各候補を3回ずつ動かし、偶然の当たりを避けます。

公式情報：Anthropic：Fable 5.1／OpenAI：GPT-6 Astra

実行コード02｜同一課題の比較評価

目的: 複数ツールに同じ課題を与え、評価条件をそろえて比較します。

前提: 品質・速度・操作性を5点満点で採点した例です。

変更箇所: weights と trials を自社の評価項目・試用結果に置き換えます。

実行方法: python codes/02_compare_same_task.py

期待結果: 候補Aが4.2点で1位になり、全候補の得点が表示されます。

"""同じ課題を複数ツールで試した結果を、重み付きで比較する。"""
weights = {"quality": 0.5, "speed": 0.2, "operability": 0.3}
trials = [
    {"tool": "候補A", "quality": 4, "speed": 5, "operability": 4},
    {"tool": "候補B", "quality": 5, "speed": 3, "operability": 3},
    {"tool": "候補C", "quality": 3, "speed": 5, "operability": 5},
]

def weighted_score(trial):
    return sum(trial[key] * weight for key, weight in weights.items())

results = sorted(((weighted_score(t), t["tool"]) for t in trials), reverse=True)
for score, tool in results:
    print(f"{tool}: {score:.1f}/5.0")

採点は5段階でも構いませんが、曖昧な「良い文章」ではなく、条件へ分けます。「指定文字数を守った」「根拠箇所を示した」「存在しない数字を足していない」「修正指示1回以内で完成した」などです。速度は生成時間だけでなく、人が完成品へ直すまでを測ります。

最終的に、全社員を一つへ統一する必要もありません。日常の文書作業を主担当へ集め、難問だけ別モデルに回す設計もできます。ただし、最初から三つを全員へ配ると教育と管理が複雑になります。まず一つを標準にし、例外が数字で説明できる部門だけ追加する方が運用しやすいでしょう。

3．大量処理では、トークン単価より「1件の総原価」を見る

APIで数百件、数千件を処理すると、単価の差が効きます。Googleが公表したGemini 3.8 FlashのAPI価格は、入力100万トークン当たり0.75ドル、出力100万トークン当たり3.75ドルです。一方、OpenAIのGPT-6 Astraは公式モデルページで最新価格を確認してから設計すべき高性能枠です。価格は変わり得るため、この記事の数字を料金表の代わりに使わないでください。

さらに大切なのは、100万トークンの値段だけでは仕事1件の原価が決まらないことです。長い推論を行うモデル、出力が冗長な設定、失敗して再実行が多い工程では、安い単価でも総額が増えます。逆に高価なモデルが一度で合格し、人の確認を10分減らせるなら安くなる場合があります。

計算式は単純です。API費用に、人の確認時間×人件費、再実行費用、月額の固定費を足し、完了件数で割ります。たとえばAPI費用が2円でも、確認に3分かかり時給3000円なら、人件費は150円です。改善すべき場所はAPI単価より確認工程かもしれません。

公式情報：Google：Gemini 3.8 Flashの機能とAPI価格

実行コード03｜API単価からタスク原価

目的: トークン費用と確認作業の人件費を合算し、1タスクの概算原価を出します。

前提: コード内のAPI単価は説明用の架空値で、実在サービスの料金ではありません。

変更箇所: 公式料金に確認した単価、実測トークン数、作業時間、時間単価へ差し替えます。

実行方法: python codes/03_task_cost.py

期待結果: 架空単価である旨と、API原価1.92円・合計151.92円が表示されます。

"""架空のAPI単価から、1タスク当たりの概算原価を計算する。"""
# 以下の単価は説明用の架空値です。実際の料金は各社の公式情報を確認してください。
price_per_million = {"input": 120.0, "output": 480.0}  # 円
usage = {"input": 8_000, "output": 2_000}  # トークン
labor_minutes = 3
labor_yen_per_hour = 3_000

api_cost = sum(usage[k] / 1_000_000 * price_per_million[k] for k in usage)
labor_cost = labor_minutes / 60 * labor_yen_per_hour
total = api_cost + labor_cost

print("単価は架空値です")
print(f"API原価: {api_cost:.2f}円 / 人件費: {labor_cost:.2f}円 / 合計: {total:.2f}円")

大量処理は、最初から全件を自動確定しません。低リスクの入力で100件を試し、人の正解と照合します。確信度が低いもの、金額が一定額を超えるもの、禁止語を含むものだけ人へ戻す仕組みにすると、安全と速度を両立しやすくなります。

また、入力と出力のトークン数、処理時間、再試行回数、モデル名、プロンプト版を記録します。翌月に価格やモデルが変わっても、同じデータで比較できます。大量処理の強さは、一回の華麗な回答ではなく、失敗を見つけて止められる運用にあります。

4．資料調査は「読ませる」と「外を探す」を分ける

社内資料を調べる仕事では、Gemini Notebook（従来のNotebookLM系）のような、与えた資料を根拠に回答する道具が便利です。Googleの公式ヘルプでは、Gemini Notebook側の回答はノート内のソースだけに基づき、Geminiアプリ側ではWeb検索なども含み得る、と説明されています。この違いは小さく見えて重要です。

規程、過去の提案書、議事録を読むときは、範囲を閉じた方が根拠を追いやすい。一方、市場規模、法令、製品価格のような最新情報は外部調査が必要です。二つを一度に頼むと、社内資料の記述とWebの情報が混ざり、どこから出た数字か分からなくなります。

長いPDFは見出し単位で分割し、文書名、版、作成日、ページ番号を付けます。OCRで文字が崩れている資料は、原文画像も残します。質問も「要約して」ではなく、「2026年度の解約条件を、条項番号と原文の短い引用付きで表にして」のように、根拠の形式まで指定します。

公式情報：Google：ノートとGeminiの違い／データの扱い

実行コード04｜資料分割

目的: 見出しを壊さずに長い資料を小さなまとまりへ分けます。

前提: 見出しは # で始まり、目安の文字数は32文字のサンプルです。

変更箇所: document と limit を対象資料と利用ツールの入力上限に合わせます。

実行方法: python codes/04_split_document.py

期待結果: 見出し単位のchunkを表示します。長い節は分断せず「上限超過」と表示するため、必要に応じて手動で分けます。

"""長い資料を、見出し単位でまとまり（長い節は上限超過と表示）に分割する。"""
document = """# 背景\n生成AIの利用部門が増えています。\n# 課題\n品質基準が部門ごとに異なります。\n# 方針\n共通の評価票を導入します。"""
limit = 32
sections, current = [], []
for line in document.splitlines(keepends=True):
    if line.startswith("# ") and current:
        sections.append("".join(current).rstrip("\n"))
        current = []
    current.append(line)
sections.append("".join(current).rstrip("\n"))
chunks = sections  # 見出しを壊さないため、長い節は上限超過を許容する
for i, chunk in enumerate(chunks, 1):
    note = "・上限超過" if len(chunk) > limit else ""
    print(f"--- chunk {i} ({len(chunk)}文字{note}) ---\n{chunk}")

調査成果物には、事実、解釈、提案を分けて書きます。「資料にはAとある」が事実、「原因はBだろう」が解釈、「次回はCを試す」が提案です。この三つが混ざると、AIのもっともらしい補完が社内の決定事項に見えてしまいます。

機密情報を入れる前には、契約するプランのデータ利用条件を確認してください。Googleの公式ヘルプでも、個人利用と対象のWorkspace利用では取り扱いの説明が異なります。製品名だけで安全性を判断せず、会社の契約、管理者設定、共有範囲、フィードバック送信時の扱いまで確認する必要があります。

5．開発はClaude Code、Cursor、Codexを役割で選ぶ

AI開発ツールは、コード補完の競争から、課題を受け取り、編集し、テストし、変更を説明する競争へ移りました。Claude Codeはターミナルからリポジトリを扱うエージェントです。Anthropicの公式文書には、対話利用だけでなく、標準入力からデータを渡し、JSONで結果を受け取る使い方も載っています。

CursorのCloud Agentsは、専用の仮想環境で機能追加、バグ修正、テストを進め、完了時にプルリクエストを作れると公式ヘルプが説明しています。手元のIDEで人が編集しながら使う場面と、長い作業をクラウドへ任せる場面を分けられます。CodexはOpenAIのコーディングエージェントとして、リポジトリを調べ、変更し、検証する用途へ置けます。

三つを「どれが最強か」で比べるより、仕事の入口で選びます。ターミナル中心の既存開発へ組み込む、IDEで対話しながら直す、複数の課題を別環境で走らせる、という違いです。どの製品でも、最初に対象フォルダ、変更してよいファイル、受け入れ条件、実行すべきテストを渡します。

公式情報：Claude Code CLI／Cursor Cloud Agents／OpenAI Developers

以下のCSV整形は、開発AIへ渡す最初の小課題の例です。「空白と状態名を整え、完全重複だけを除き、入力を上書きしない」という受け入れ条件と一緒に使えます。

実行コード05｜CSV整形

目的: 余分な空白、状態名の表記ゆれ、完全重複をまとめて整えます。

前提: UTF-8の小さなCSVを文字列として内蔵しています。

変更箇所: source を読み込んだCSV文字列に、aliases を社内の正規表記に変更します。

実行方法: python codes/05_clean_csv.py

期待結果: 2行に重複排除され、状態が「未着手」「完了」に統一されます。

"""表記ゆれと空白を整え、重複行を除いたCSVを出力する。"""
import csv
import io

source = "会社名,担当,状態\n 株式会社青空 ,佐藤, 未対応\n株式会社青空,佐藤,未対応\n白波商事, 鈴木 ,対応済み\n"
aliases = {"未対応": "未着手", "対応済み": "完了"}
rows, seen = [], set()
for row in csv.DictReader(io.StringIO(source)):
    clean = {key: value.strip() for key, value in row.items()}
    clean["状態"] = aliases.get(clean["状態"], clean["状態"])
    key = tuple(clean.values())
    if key not in seen:
        rows.append(clean); seen.add(key)
out = io.StringIO(newline="")
writer = csv.DictWriter(out, fieldnames=["会社名", "担当", "状態"])
writer.writeheader(); writer.writerows(rows)
print(out.getvalue().strip())

評価指標は生成した行数ではありません。人の介入なしで完了した割合、テスト合格率、レビュー差し戻し率、既存機能を壊した件数、担当者の確認時間です。簡単な修正を大量に成功させても、重要な一件で権限外のファイルを変えれば、運用としては失格です。

本番導入は、文書修正や小さなテスト追加から始めます。変更は必ず差分で見て、CIを通し、別の人か別工程でレビューします。開発AIは速い新人というより、明確な作業範囲と検収条件があると力を出す外部チームに近い存在です。

6．根拠台帳と小さな自動化アプリが、AIを業務に変える

チャットの回答をコピーして終わると、翌月には再現できません。誰が、どの資料を使い、どのモデルと指示で、何を出し、人がどこを直したか。この記録を「根拠台帳」として残すと、個人の便利技が会社の工程になります。

最低限の列は、案件ID、実行日時、入力資料、資料の版、モデル、指示の版、出力先、確認者、判定、修正理由です。個人情報や本文そのものを台帳へ重複保存する必要はありません。保管場所への参照とハッシュ値を使えば、対象の版を確かめられます。

次に、よく使う手順を小さなアプリへします。問い合わせ分類なら、メール本文を貼る、候補部署と理由が出る、人が確定する、結果が台帳へ残る、という四画面で十分です。最初から全社基幹システムへ直結させるより、入力と承認を限定した道具の方が改善しやすくなります。

実行コード06｜根拠台帳の未確認抽出

目的: 記事や提案書の主張から、未確認または出典なしの項目を抽出します。

前提: 各項目は主張・出典・確認済みフラグを持つ想定です。

変更箇所: ledger を実際の根拠台帳に置き換えます。

実行方法: python codes/06_unverified_evidence.py

期待結果: 確認が必要な2件と、それぞれの理由が表示されます。

"""根拠台帳から、未確認または出典不足の主張だけを抽出する。"""
ledger = [
    {"claim": "処理時間が半減", "source": "計測ログ2026-09", "verified": True},
    {"claim": "顧客満足度が向上", "source": "", "verified": False},
    {"claim": "入力ミスが減少", "source": "品質集計Q3", "verified": False},
]

pending = [
    item for item in ledger
    if not item["verified"] or not item["source"].strip()
]
for item in pending:
    reason = "出典なし" if not item["source"] else "確認待ち"
    print(f"要確認: {item['claim']}（{reason}）")

自動化には必ず「止まる条件」を入れます。根拠がない、必須項目が欠ける、金額が基準を超える、同じ処理が連続失敗する、といった場合です。AIが自信ありげに書いた文章を確信度の代わりにしてはいけません。ルールで判定できる条件は、通常のプログラムで止めます。

経営者が見る画面には、生成回数より、完了件数、削減時間、差し戻し率、事故件数を出します。利用回数が増えても、手直しが増えれば成功ではありません。根拠台帳があれば、モデル変更の前後で品質を比較し、悪化したら元へ戻せます。

7．画像生成は、一発の美しさより修正可能性で選ぶ

画像生成は、広告、提案書、SNS、商品説明で使い道が広がりました。OpenAIの公式開発者ページでは、GPT Image 2.5に精密な編集向けのSunburstと、高速生成向けのFlareが案内されています。Googleや他社にも複数の選択肢がありますが、モデル名は更新が速いため、契約時に公式ページで現行版を確認してください。

実務で見るべきは、最初の一枚の派手さだけではありません。日本語文字が読めるか、指定サイズを守れるか、人物や商品の特徴を維持したまま一部を直せるか、同じ雰囲気で展開できるかです。バナーなら、見出しを後から編集できる余白と、ロゴを置く安全域も必要です。

プロンプトには、目的、対象読者、媒体、比率、主役、背景、色、光、文字の有無、避けたい表現を書きます。例なら「製造業の経営者向けセミナー告知。16:9。落ち着いた紺と白。中央右に人物、左側は見出し用の余白。画像内文字なし」です。固有の作家名へ寄せるより、構図や質感を言葉で説明します。

GoogleのNano Banana 2も、生成と編集の候補です。既にGeminiを業務で使う会社は、まず同じ商品写真と同じ修正指示で試すと、道具を増やす価値があるか判断できます。ここでの推奨は優劣の断定ではなく、既存環境に合う候補から検証する順番です。

公式情報：OpenAI：GPT Image 2.5／Google：Nano Banana 2

実行コード07｜制作ブリーフJSON検証

目的: 画像を作る前に、目的・対象・メッセージなどの指示漏れを検査します。

前提: これは画像寸法の検査ではなく、制作ブリーフの内容検証です。

変更箇所: required に自社の必須項目を追加し、brief_json を案件データへ置き換えます。

実行方法: python codes/07_validate_creative_brief.py

期待結果: 「制作ブリーフ: OK」と整形済みJSONが表示されます。

"""画像制作そのものではなく、制作ブリーフJSONの必須項目を検証する。"""
import json

brief_json = '''{
  "purpose": "note記事の見出し画像",
  "audience": "生成AIの導入担当者",
  "message": "小さく試して数字で選ぶ",
  "tone": "信頼感があり明快",
  "deliverables": ["16:9", "1:1"]
}'''
required = {"purpose", "audience", "message", "tone", "deliverables"}
brief = json.loads(brief_json)
missing = sorted(required - brief.keys())
invalid = [key for key in required - {"deliverables"}
           if not isinstance(brief.get(key), str) or not brief[key].strip()]
items = brief.get("deliverables")
if not isinstance(items, list) or not items or any(
    not isinstance(x, str) or not x.strip() for x in items or []
):
    invalid.append("deliverables（空でない文字列の配列が必要）")
status = "OK" if not missing and not invalid else f"要修正 missing={missing}, invalid={invalid}"
print(f"制作ブリーフ: {status}")
print(json.dumps(brief, ensure_ascii=False, indent=2))

制作では、①ラフを低コストで複数作る、②構図を一つ選ぶ、③ブランド色と商品を合わせる、④文字はデザインツールで載せる、⑤権利と事実を確認する、という順が安定します。人物写真に見える画像は、実在人物と誤解されない表示や利用場面も検討します。

評価は、採用率、修正回数、完成までの時間、ブランド基準違反で測れます。生成枚数が多いほど成果が出るわけではありません。必要なサイズと構図を再現でき、担当者が短時間で直せるモデルが、現場では強いのです。

8．動画と音楽は、短い試作から制作工程へ組み込む

動画生成では、Google DeepMindがVeo 3.1を映像と音声を扱う最新モデルとして紹介し、プロンプト追従、創造的な制御、一貫性を訴求しています。動画は静止画より確認項目が多く、人物、物体、カメラ、音声、尺のどれかが崩れることがあります。公式の優れた例だけで、自社素材でも同じ結果になるとは限りません。

最初の用途は、完成CMの全自動生成より、絵コンテ、背景案、短い説明カット、既存映像の補助が向いています。例として、採用動画の冒頭5秒を3案作り、社内撮影の前に構図を決める使い方です。失敗しても事業への影響が小さく、人の制作判断を速められます。

音楽生成も同じです。曲を作れることと、商用制作で安心して使えることは別です。利用規約、契約プラン、地域、公開方法により条件が変わり得ます。歌詞、声、既存曲との類似、権利処理を確認し、公開日には利用条件の記録を保存します。

用途から候補を絞るなら、映像と音声をまとめて試す候補にVeo 3.1、30秒の物語と参照素材の制御を重視する候補にSeedance 2.5、生成後の制作環境まで見る候補にRunwayを置きます。ByteDanceはSeedance 2.5で一度に最大30秒の生成を案内し、RunwayはGen-4.5の動きと指示追従を訴求しています。音楽では、9月9日発表のSuno v6が試用候補です。いずれも同じ絵コンテや歌詞で少数を試し、採用できた成果物で比べます。

公式情報：Google：Veo 3.1／ByteDance：Seedance 2.5／Runway：Gen-4.5／Suno：v6

実行コード08｜動画絵コンテCSV生成

目的: 秒数・画・ナレーションを編集担当に渡せるCSVへ変換します。

前提: 20秒動画、3シーンの構成例です。

変更箇所: scenes に尺と演出を追加し、必要なら列名も変更します。

実行方法: python codes/08_storyboard_csv.py

期待結果: ヘッダーと3シーンを含むCSVが表示されます。

"""動画の構成案から、編集担当へ渡せる絵コンテCSVを生成する。"""
import csv
import io

scenes = [
    {"秒": "0-5", "画": "散らかった業務一覧", "ナレーション": "AI導入、何から始めますか？"},
    {"秒": "5-12", "画": "優先度表", "ナレーション": "効果とリスクで順番を決めます。"},
    {"秒": "12-20", "画": "計測グラフ", "ナレーション": "導入後は同じ指標で測ります。"},
]
out = io.StringIO(newline="")
writer = csv.DictWriter(out, fieldnames=["秒", "画", "ナレーション"])
writer.writeheader(); writer.writerows(scenes)
csv_text = out.getvalue().strip()
print(csv_text)

動画用の指示は、場面を一文へ詰め込まず、秒数ごとに分けます。「0〜2秒：机上の製品を固定カメラで表示。2〜5秒：ゆっくり寄る。字幕なし。環境音のみ」のようにします。登場人物、服装、光、カメラ位置を固定し、変更する項目を一つずつにすると比較しやすくなります。

費用は生成1回の価格ではなく、採用できた秒数当たりで見ます。10本作って1本だけ使えたなら、9本分も制作原価です。修正に編集者が使った時間も含めます。短い試作を経て、どの工程をAIへ渡し、どこを人が仕上げるかを決めるのが現実的です。

公開前チェックには、映像の不自然さだけでなく、字幕、固有名詞、発音、背景に映る文字、商品仕様を含めます。音量や縦横比など配信先の条件も確認します。動画は一部の誤りが短時間しか映らず、静止画より見落としやすい媒体です。担当者は通常速度とコマ送りの両方で確認し、承認した版を固定します。

9．MCPとローカル運用は、権限を小さく始める

MCPは、AIから外部のデータや道具を使うための共通の接続方法です。うまく使えば、予定を読む、社内検索をする、チケットを作る、といった操作を一つのエージェントから呼べます。一方で、接続先が増えるほど、誤操作や不正な指示の影響範囲も広がります。

MCPの2026年7月28日付リリース候補の公式説明は、OAuthやOpenID Connectに沿った認可強化を示していますが、規格に対応しただけで安全が完成するわけではありません。読む権限と書く権限を分け、最初は読み取り専用にします。書き込みは対象、上限、期限を絞り、外部送信、削除、支払い、本番変更には人の確認を置きます。

接続するツールの名前、提供元、必要権限、保存データ、管理者、失効手順を台帳にします。使わなくなった接続を残さず、トークンはソースコードやチャットへ貼りません。MCPサーバーから返る説明や外部文書も、信頼済みの命令ではなく入力データとして扱います。

公式情報：MCP：2026年7月の仕様リリース候補

実行コード09｜操作許可の判定デモ

目的: 操作ごとに自動許可・承認確認・拒否を割り当てる考え方を示します。

前提: 説明用の判定デモであり、認証・認可など実際の防御機構ではありません。

変更箇所: rules を社内ルールの検討材料として編集します。本番制御には専用の認可機構が必要です。

実行方法: python codes/09_permission_decision_demo.py

期待結果: 説明用デモの注意書きと、4操作の判定が表示されます。

"""操作内容に応じて承認要否を返す、説明用の判定デモ。"""
# これは考え方を示すデモであり、認証・認可など実際の防御機構ではありません。
rules = {
    "read_draft": "allow",
    "save_draft": "allow",
    "send_email": "ask",
    "publish": "ask",
    "delete_records": "deny",
}

def decide(action):
    return rules.get(action, "deny")

checks = ["read_draft", "send_email", "delete_records", "unknown_action"]
results = {action: decide(action) for action in checks}
print("説明用デモ（実際の防御機構ではありません）")
for action, decision in results.items():
    print(f"{action}: {decision}")

クラウドへ出せない情報では、ローカルモデルも候補です。ただし「ローカルだから完全安全」とは言えません。端末の盗難、マルウェア、誤った共有、ログの残存、更新停止は起こり得ます。性能も機器、量子化、文脈長、同時利用数で変わります。

クラウドかローカルかは二択にせず、情報分類で分けます。公開情報はクラウド、社内限定は法人契約と管理設定の下で利用、特に機密性が高い資料は閉じた環境、という設計です。最小権限、監査ログ、更新、バックアップ、事故時の停止方法まで用意して初めて運用になります。

権限の試験では、正常に読めることだけでなく、読めてはいけないデータへ到達できないことも確かめます。テスト用アカウントで、部署外のフォルダ、期限切れトークン、許可されていない書き込みを試します。退職や異動時に誰が接続を解除するかも決めます。便利な連携ほど、入口より出口の管理が忘れられがちです。

10．二週間で導入し、効果を数字で判定する

導入計画は、半年の全社変革より二週間の小さな検証から始めます。対象業務は一つ、担当者は3〜5人、処理件数は30〜100件程度にします。開始前に現状の時間、品質、件数を測らないと、導入後に「便利になった気がする」で終わります。

1〜3日目は業務を棚卸しし、合格条件と停止条件を決めます。4〜7日目は、匿名化した同じ課題で候補を比較し、主担当のツールを一つ決めます。ここまでで実運用へ進めない問題が見えたら、権限を広げず修正します。

8〜10日目は入力と出力の形式を固定し、利用条件を確認した少量の実データで、人が全件を確認しながら動かします。誤りの種類を「事実誤認」「形式違反」「根拠不足」「入力不足」に分けます。この期間に、頻出する失敗をプロンプト、資料、通常コードのどこで防ぐか決めます。AIへ注意文を足すだけでなく、入力チェックや上限判定をプログラムに任せます。

実行コード10｜導入前後の効果測定

目的: 導入前後を同じ指標で比較し、時間・品質・コストの変化率を出します。

前提: 各数値は同じ条件・同じ期間で測った想定のサンプルです。

変更箇所: before と after を実測値に差し替えます。

実行方法: python codes/10_measure_before_after.py

期待結果: 時間60.0%削減、品質13.0ポイント改善、コスト45.8%削減と表示されます。

"""導入前後の時間・品質・コストを、同じ指標で比較する。"""
before = {"minutes": 45, "quality": 78, "cost_yen": 2400}
after = {"minutes": 18, "quality": 91, "cost_yen": 1300}

def reduction(old, new):
    return None if old == 0 else (old - new) / old * 100

metrics = {
    "時間削減率": reduction(before["minutes"], after["minutes"]),
    "品質改善幅": after["quality"] - before["quality"],
    "コスト削減率": reduction(before["cost_yen"], after["cost_yen"]),
}
for name, value in metrics.items():
    unit = "ポイント" if name == "品質改善幅" else "%"
    print(f"{name}: {value:.1f}{unit}" if value is not None else f"{name}: 算出不可（導入前が0）")

11〜13日目は、担当者以外が同じ手順を再現できるか確かめます。14日目に、作業時間、合格率、差し戻し率、人の確認時間、1件の総原価、重大な誤りを導入前と比較します。目標例は「平均作業時間を30％削減し、重大な誤りを増やさない」です。数字は業務ごとに設定してください。

継続の判断は三つです。効果が出たら対象を少し広げる。品質は良いが確認時間が長ければ工程を直す。重大な誤りが減らなければ、用途を限定するか停止する。モデルを替えるのは、その後です。

2026年9月に価値があるのは、特定の一社を信じ切ることではありません。仕事を分け、同じ条件で試し、根拠と費用を記録し、小さな権限で動かすことです。生成AIの更新はこれからも続きます。選定基準と検証データを自社に残せば、モデル名が変わっても、導入判断はぶれません。

AIに仕事を任せる会社が、最初に決めるべき「権限の境界」

「効いた気がする」を卒業する。AI効果シミュレータを5ファイルでつくり、社内で使える形にするまで

鈴木章裕

株式会社コミクス代表取締役