AIを使いこなす人は、仕事をどう任せているのか｜2026年6〜9月の実践から

AIで文章を作るのは速くなった。でも、資料を探して貼り付け、次の指示を出し、結果を確かめる作業は残っている。そんな場面で、AIを使い込んでいる人たちは何をしているのでしょうか。

2026年6〜9月に公開された、開発者・研究者・実務担当者の発信を調べました。そこから見えてきたのは、目的と資料を渡し、仕事の流れを用意し、完成を確かめる使い方です。うまい質問文を書くことに加えて、仕事を任せる仕組みそのものを整えています。

この記事では、具体的な実践、その背景、確認できた効果を整理します。限られた公開事例からの考察であり、上級利用者全体の傾向を統計的に示すものではありません。

六つの実践と、解決したい課題

実践	解決したい課題
必要な資料と完成形を一緒に渡す	検索・コピー・再指示で人が待ち続ける
繰り返す手順を再利用する	毎週、同じ説明と集計をやり直す
予定や出来事を起点に動かす	忙しいと準備や確認が後回しになる
作成とレビューを分ける	作ったAIが自分の見落としに気づきにくい
動作や保存を確かめる	「完了」という返事だけでは実態が分からない
指示を足すだけでなく整理する	ルールが重複し、費用や判断の負担が増える

1．資料と完成形を渡し、途中の受け渡しを減らす

Wharton教授のEthan Mollick氏は7月23日の記事で、メールに接続したAIに授業の準備を任せた試行や、出版前の書籍PDFの引用を点検させた例を紹介しています。書籍の195件の参照を約30分で調べたというのは本人の報告です。指摘の正しさも本人が評価しており、人間との対照実験ではありません。出典：Mollick氏の実践報告

参考になるのは、「検索して」「次に要約して」と一工程ずつ頼む代わりに、必要な資料と到達点をまとめて渡すことです。人が情報を運ぶ回数を減らせます。

たとえば中小企業の商談準備なら、公開された会社情報と面談の目的を渡し、「事実・仮説・当日確認したい質問を分けた1枚」を作ってもらう。これは本記事の応用例です。AIに接続する資料の範囲は決め、顧客情報を無差別に渡さないことも準備に含めます。

同氏の試行では、以前の送信許可を引き継いだAIが実際にメールを送った例もあります。資料を読む、下書きを作る、相手へ送るという権限は、それぞれ決めておく必要があります。

2．毎週の仕事を、再利用できる手順にする

Anthropicのマーケティング実務担当者が登壇した8月6日のイベント案内では、業務システムとの接続とSkillsを使った週次レポート作成が紹介されています。Skillsは、繰り返す作業の手順をAIが参照できる形にまとめたものです。担当者側は所要時間を2日から2時間へ縮めたと説明しています。出典：Anthropic公式イベント案内

これは提供企業の自社申告です。今回、録画や元の作業ログは検証しておらず、「2日」が実働何時間かも不明なため、削減率には換算しません。

毎週の集計には、数字を集めるだけでなく、集計範囲、用語、前週比較、報告先の形式などの決まりがあります。その手順を一度整理すれば、毎回の説明を減らせます。

自社で試すなら、まず一つの週次報告に絞ります。「どの数字を、どの期間で集め、誰がどこを確認するか」を短く書き、過去の完成例を一つ添える。接続するツールの数より、同じ条件で再現できるかを見たいところです。

3．予定をきっかけに動かし、次回へ記録を残す

佐々木優希氏／AIリモートワーカーは9月18日の記事で、商談予定がカレンダーに入ると、前夜に公開情報の調査、仮説、質問、提案骨子を用意する仕組みを報告しています。商談準備は90分から13分へという自社計測ですが、独立した監査や反復測定の結果は確認できていません。出典：同氏の業務自動化事例

毎回、人が「そろそろ準備して」と頼む方式では、忙しい日に止まります。予定を起点にする設計は、その起動忘れを減らすための工夫です。

開発者のAddy Osmani氏も6月7日の記事で、定期的に課題を探し、作業と検証を分け、試したことや未完了をファイルに残す運用を紹介しています。定量的な時間削減は示していませんが、いつ始め、何をもって終え、次回へ何を残すかを設計する考え方が参考になります。出典：Loop Engineering

小さな会社なら、まずは「商談前日に公開情報を調べ、社内の所定場所へ下書きを保存する」程度から試せます。送信や公開の判断は、人が結果を読んで行います。

4．作るAIと、確かめるAIを分ける

Datasetteの開発者Simon Willison氏は7月5日、sqlite-utilsの公開前レビューと修正をClaudeで進め、最後にGPTで再レビューした例を公開しました。追加で指摘された2件の問題を別のセッションで再現し、修正したと報告しています。本人も文書やコードの差分を確認しています。出典：sqlite-utilsの開発記録

別モデルを使えば必ず品質が上がる、という比較実験ではありません。それでも、作成した流れから離れて確認し、指摘を実際に確かめた点には意味があります。

提案書なら、作成後に別の会話で「根拠のない数字、顧客の課題と解決策のずれ、約束しすぎている表現を挙げて」と頼めます。指摘された箇所は元資料へ戻って確認する。レビューの返答を、そのまま正解とは扱わないことが大切です。

5．「完了」の返事と、成果物の存在を照合する

前述の佐々木氏は、別の自動化処理で8本のnote下書きが存在せず、約3週間気づかなかったことも報告しています。その後、保存された下書きIDの存在を照合する処理を加えています。出典：同氏の失敗と改善の記録

動いたというログと、使える成果物が保存されたことは別です。ここは営業資料、社内レポート、ブログなどにも共通します。

Willison氏は6月30日、AIにデモ環境と操作手順を用意させ、開発した機能のブラウザー操作を動画で提出させる方法も紹介しました。動画と手順が公開されていますが、時間削減率や欠陥の検出率は測定されていません。出典：操作動画を記録させる実践

成果物に合わせて、保存先のファイルを開く、集計値を元データと照合する、画面を操作してみる。何を見れば完成を確かめられるかを、依頼時に決めるのが実用的です。

6．ルールを増やす前に、必要な指示へ整理する

Claude Code開発者との7月21日の対談では、最上位モデル向けの指示から古い例や重複を減らし、理由と文脈を伝える形へ改めた話が出ています。system prompt、つまりシステム側の基本指示を80%短縮したというチーム報告です。全トークンや料金が80%減ったという意味ではありません。古いモデルには長い指示も継続しています。出典：Claude Code開発者との対談

一方、8月公開のWeb開発Skillsの研究では、対象の手順を追加した条件で、平均成績が下がり、トークンコストが72〜394%増えたと報告されています。改善した組み合わせもあり、特定のタスク・モデル・与え方での結果です。出典：Signal or Noise?

便利そうな手順を集めるだけでは、仕事に合うとは限りません。自社でよく行う同じ作業を、手順あり・なしで比べ、品質、修正時間、費用を確認する。うまくいかなかった場合も指示を継ぎ足し続けず、重複や矛盾を見直す余地があります。

自社で始めるなら、一つの仕事を三回試す

今回の調査から、最初に試す形として次の手順を提案します。三回は、小さく確認を始めるための目安です。

毎週ある仕事を一つ選ぶ。 商談準備、週次報告、資料の点検など、完成形が分かるものにする。
目的・資料・完成条件を書く。 読める資料、保存先、人が承認する場所を決める。
同じ条件で三回試す。 AIの実行時間に加え、人の準備・確認・修正時間と費用を記録する。
役立った手順を残す。 保存漏れや誤りも記録し、次回の確認項目に加える。

見る数字は、AIが何時間動いたかより、人の確認まで含めて、使える成果物をどれだけ少ない手間で作れたかです。

経営として何を判断したいか。現場でどの情報を扱えるか。完成したことを誰がどう確かめるか。この三つを一緒に考えると、AIに任せる仕事も具体的になります。次の商談準備や週次報告を一つ選び、まずその流れを書き出してみてください。

対象は2026年6月1日〜9月30日に公開された一次資料。2026年10月4日に調査・編集しました。実践の成果は当事者の報告、研究結果はその評価条件に限ります。中小企業向けの応用例と試行手順は、本記事の提案です。