【Claudeが示す落とし穴】AIが賢くなるほど、人間の判断は怪しくなる

はじめに

本連載は、生成AIコミュニティ「IKIGAI lab.」で活動しているメンバーが、それぞれの視点から最新のAIトレンドとビジネスへの示唆を発信しています。

2026年1月の記事「【2026年の新常識】「良い質問」より「良い前提」。生成AIを動かすコンテキスト設計」と2月の記事「【arXiv最前線】自律型AIに潜む「信頼できない思考プロセス」」では、AIをうまく使うためには「良い前提」の設計が重要であること、そして自律型AIの思考プロセスそのものには信頼できない側面があることを整理してきました。こうした流れを踏まえつつ、2026年4月時点ではさらに具体的な動きが出てきています。

OpenAIは2026年4月23日、GPT-5.5を発表しました。コーディング、オンライン調査、データ分析、ドキュメント作成、ソフトウェア操作、複数ツールをまたぐ作業を強みとして公式に説明しており、曖昧な目標を与えても自律的に計画・実行・検証まで進むエージェント型の設計が特徴とされています。

AnthropicはClaude Opus 4.7を4月16日に一般提供開始し、複雑なコーディングタスクと指示追従の大幅な改善を打ち出しています。

Googleも4月22日にGemini Enterprise Agent Platformを発表し、Vertex AIの後継として、企業内でのエージェント構築・運用・管理を一元化する方向性を強めています。

3社の動向に共通するのは、AIが『答える道具』から『作業を進める存在』へ変わりつつあるという方向性です。

この変化を実務レベルで考えるうえで、いま特に注目を集めているのがAnthropicのClaude Skills、Claude Code、Claude Coworkです。業務の型をAIに渡す仕組みとして、実務家やエンジニアの間で急速に関心が高まっています。本記事ではこれらの機能群を題材に、AIにどこまで任せるべきかを考えます。

AIが「業務の型」を読み込む。Claude Skillsとは何か

Claude Skillsは、特定のタスクをより適切に実行するために、Claudeに与える指示・手順・参照資料のまとまりです。これらを入れておくと、Claudeはタスクに関連するスキルを見つけて必要な情報だけを読み込み、活用します。

実際に使い込むと、単なる「便利機能」ではないことが分かります。スキルに入れるべきものは、製品情報や過去資料のような知識よりも、「どの順番で考えるか」「何を見落としてはいけないか」「何をもって良いアウトプットとするか」という判断の構造です。

どのようなスキルが作れるのか、構成の一例を示します。

このリストで重要なのはスキルの数ではなく、各スキルの設計の仕方です。「いつ使うか」「何をトリガーにするか」「どこまでの範囲を担うか」、そしてスキル同士がどう連携するかを明文化することで、AIが人間の業務手順に近い形でタスクを実行できるようになります。これはAIへの指示書というより、業務そのものを言語化する作業です。

Claude Codeが示す、AIに動く環境を与えるということ

Claude Codeは、ターミナル上で動くエージェント型のコーディングツールです。コードベースを読み、ファイルを編集し、コマンドを実行し、複数ファイルにまたがる修正やテストまで支援します。

Claude Codeを使う際に重要になるのが、「.claude/」ディレクトリを中心としたプロジェクト構成の設計です。公式ドキュメントが示す標準的な構成は以下のようになります。

このうち最も重要なのが CLAUDE.mdです。Claudeはセッション開始時にこのファイルを自動で読み込み、プロジェクトの構造・コーディング規約・実行コマンド・禁止事項を把握します。何を書くか、どこまでを制約として明示するか、この設計の質が、AIの出力品質を直接左右します。

【参考】「Anthropic社「Claude Code Best Practices」(公式ドキュメント)」

「ハーネスエンジニアリング」プロンプト設計の先にある考え方

こうした設計の実践には、「ハーネスエンジニアリング」という名前がついています。「ハーネスエンジニアリング」は、HashiCorpの共同創業者Mitchell Hashimotoが2026年2月に提唱(Harness Engineering: The Execution Layer AI Agents Actually Need)し、OpenAIとAnthropicがそれぞれ公式記事を発表したことで業界に広まりました。定義はシンプルで、「モデル自体を除いた、AIエージェントを取り巻く環境・ツール・制約・フィードバックループ全体を設計・構築・改善する実践」です。

ハーネスとは、もともと馬具を意味する言葉です。そこから転じて「AIという強力だが制御の難しい力を、目的の方向に正しく導くための装置・仕組み一式」を指しています。式で表すと次のようになります。

馬がどれだけ速くても、手綱と鞍がなければ制御できません。モデルとハーネスの関係もこれと同じです。より良い成果をもたらすのは「良いモデル」ではなく、「良いハーネス」であることが多いとされており、CLAUDE.mdや「.claude/」以下の設定群を丁寧に設計することが、まさにハーネスエンジニアリングにあたります。

もちろん、Claude Skillsもハーネスの構成要素として捉えられます。スキルに「いつ使うか」「何をトリガーにするか」の説明を定義すること、SKILL.mdに判断の順序・禁止事項・出力の評価基準を書き込むことは、エージェントが動く環境を設計する行為そのものです。

ハーネスの構造を変えると、何が変わるか

Anthropicが行った「計画・生成・評価」の3エージェント構成の実験では、単一エージェントと比べて出力品質が「技術的には動くが壊れている」状態から、「単一エージェントでは試みもしなかった機能まで含む完全動作」へと大きく改善したと報告されています。まさにモデルを変えたからではなく、ハーネスの構造を変えた結果です。

しかし、ハーネスを丁寧に設計すればするほど、別のリスクが生まれます。

「整った出力」が判断を止める。自動化バイアスという落とし穴

AIの出力が実務に近づくほど、人間は「これでよさそうだ」という感覚を持ちやすくなります。

この現象は「自動化バイアス(Automation Bias)」と呼ばれており、人間がシステムの判断に過度に依存し、矛盾する情報があっても意思決定をシステムに委ねてしまう傾向を指します。AIの出力が整っているほど、人間はその内容を批判的に読む前に「正しそうだ」と判断してしまいます。専門家でも例外ではなく、むしろシステムへの習熟度が高いほど、確認を省略しやすくなる点が厄介です。

実務で起きやすい自動化バイアス

実務で起きやすい自動化バイアスのパターンは3つあります。

判断と責任は人間が持ち続ける。Claude Coworkを機能させる

Claude Coworkは、コードを書かなくても、ローカルファイルや日常業務アプリをまたいで調査・整理・文書作成を自律的に進める非技術職向けのエージェント機能です。業務の大部分をAIが担ってくれる、非常に強力な機能で、Claudeの強みの一つです。

しかしAnthropicは、この機能について「重要な意思決定はユーザー側に残る設計」と説明しています。ユーザー側にその心構えがなければ、この設計は機能しません。ここで問われるのが、次の4つの実践です。

まとめ：AIが便利になるほど、問われるのは人間側の構造設計

Claude Opus 4.7、GPT-5.5、Gemini Enterprise Agent Platformに共通するのは「AIが作業を担う範囲の拡大」という方向性です。ただし、AIが実務に近い成果物を出せるようになるほど、過信のリスクは大きくなります。自動化バイアスが示すように、整った出力は人間の批判的思考を止めます。

こうした中で、SNSでは「AIの便利な使い方」が毎日流れてきますが、それが実務で本当に機能するかどうかは、環境設計の質で決まります。AIが動く環境を設計できるか。AIが最適化している前提を疑えるか。最終的な判断に誰が責任を持つかを明確にできるか。これらを意識できるかどうかが、AI活用の質を分けます

この問いに答えるのが仕組みを設計し、出力を監査し、判断に責任を持ち続ける構えを示す「ハーネスエンジニアリング」という概念で、本記事で示したClaude Skillsの設計や4つの実践は、その具体的な出発点です。自分の仕事の構造を理解し、どこまでを任せ、どこからを人間が担うかを設計し続けてみてください。