「もう手放せない」という声を、自分の会社で確かめる
最近、X でClaudeの仕事向けの機能が評判になっています。
開発の現場では、プログラムの変更をAIが自動で見直す「Claude Code Review」を使うと、本番に出す前にほとんどの不具合が見つかる、という声が出ています。スライドを作る「Claude Slides」については、素材を探す手間がなくなった、という紹介が伸びました。最新のモデル（AIの頭脳にあたる部分）であるOpus 5.5を、今いちばん良いと評価する投稿も目立ちます。
なぜ、こうした投稿が広がるのでしょうか？
理由は単純です。実際に使っている人の「もう手放せない」という声は、企業の宣伝よりも信用されやすいからです。
ただ、ここで一つ、つまずきやすい場面があります。評判を読んで、ためしにClaudeを開く。それらしいスライドが出てくる。「すごいな」と思って画面を閉じる。翌週の会議資料は、結局いつもどおり自分で作っている。AIは触ったのに、仕事は何も変わっていない。読者の方にも、同じ場面があるのではないでしょうか？
他人の「手放せない」は、その人の仕事で手放せないという話です。あなたの会社の仕事で手放せるかどうかは、まだ誰も確かめていません。
そこで今回は、毎週社内で作っている報告スライドを1本だけ選び、Claude Slidesに任せてみる、という小さな実験を提案します。比べるのは出来栄えより、かかった時間です。
その実験には、僕が講義の第1回で話している「頼み方の一文」をそのまま使います。評判の機能を評判で終わらせず、自分の会社の数字に変える。今日はその手順を、コピーして使える形でお渡しします。
不具合が「本番の前」に見つかる仕組みは、経営の書類にも効く
Claude Code Reviewの評判を、僕は開発だけの話とは読んでいません。
大事なのは「本番に出す前に」見直しが入ることです。プログラムでも書類でも、間違いは出した後に見つかるほど、直す手間が大きくなります。出す前に一度、変更の中身を確かめる工程があるから、不具合がほとんど残らない。この仕組みは、エンジニアでなくても使えます。
講義の第1回では、ファイル名の統一を例に、同じ考え方を話しています。AIにファイルの名前を一括で変えてもらうとき、いきなり実行させない。「変更前後の対照表を作成してから実行してください」と一文足す。表を見て、気になる行だけ直してから実行すれば、元の名前を失いません。
スライドづくりも同じです。いきなり完成品を作らせると、見た目は整っていても、使う数字や並び順が自分の意図とずれることがあります。そのずれに気づくのは、たいてい会議の直前です。先に「どのページに何を載せるか」の一覧を出させ、そこで直す。完成品を直すより、一覧の1行を直すほうがずっと早く済みます。
もう一つ、講義で繰り返しているのがAIの活用レベルです。レベル1は聞く、2は一緒に作る、3は任せる、4は連携させる、5は自律させる。そして、2と3の間には大きな段差があります。
評判のスライド機能を一度触っただけなら、まだレベル2です。毎週の報告を「任せる」ところまで進めるには、何を、どの順で、どの数字で作るのかを文章で渡せる必要があります。段差を越える根っこは、道具の知識ではありません。狙ったことを言葉にする力です。一覧や対照表を先に出させる頼み方は、その言語化をAIと一緒に練習する方法でもあります。
今日そのまま試せる、報告スライド1本の実験手順
手順は4つです。
1つ目。毎週作っている報告スライドを1本だけ選びます。週次の売上報告、営業の進み具合、店舗の数字など、何でもかまいません。先週それを作るのに何分かかったかを、ざっくり紙に書いておきます。
2つ目。Claude Slidesに、次の指示文を貼り付けます。［］の中は自分の仕事に合わせて書き換えてください。
今週の［営業報告］のスライドを作ります。
読み手は［社内の部長］、会議で使える時間は［10分］です。
材料は、このあと貼る［今週の数字のメモ］だけを使ってください。
作る前に、ページごとに「見出し」「載せる数字」「その数字の出どころ」を並べた一覧表を出してください。
僕が一覧を確認して「進めてください」と書くまで、スライドは作らないでください。
3つ目。出てきた一覧表を見て、気になる行だけ直します。講義で話した「対照表を先に出させる」と同じ役割です。直し終えたら「進めてください」と送ります。
4つ目。できあがったら、かかった時間を先週の数字の横に書きます。一覧を直した時間も含めて数えます。
できたスライドを保存するときは、もう一つの指示文が使えます。
このフォルダにある報告スライドのファイル名を「日付_報告の名前」の形にそろえてください。
変更前後の対照表を作成してから実行してください。
ファイルは削除せず、名前の変更だけにしてください。
最初は、消えても困らないフォルダで試します。中身をコピーした練習用のフォルダで十分です。
比べるときの注意が一つあります。1回目は一覧を直す時間がかかるぶん、普段より遅くなることもあります。2週目、3週目と同じ指示文を使い回し、直す行が減っていくかを見てください。直す行が減るほど、あなたの会社の書き方がAIに伝わっているということです。
僕なら、評判の機能を「1本・1つの数字」で判断する
今回の話を振り返ります。
Xでは、Claude Code Reviewで本番前にほとんどの不具合が見つかる、Claude Slidesで素材探しの手間がなくなった、Opus 5.5が今いちばん良い、という声が伸びています。使っている人の本音だからこそ、信用されやすい。ここまでは確かです。
ただ、その声があなたの会社に当てはまるかは、あなたの仕事で確かめるしかありません。大きな導入計画はいりません。報告スライドを1本だけ任せ、かかった時間を先週と比べる。数字が1つ手に入れば、判断できます。
頼み方の芯は、講義の第1回と同じです。いきなり実行させず、先に一覧や対照表を出させる。人が確かめてから進める。ファイルは削除せず、名前の変更や移動にとどめる。開発の現場で、本番前の見直しが不具合を減らしているのと同じ順番です。
自分がいまどのレベルにいるかも、ついでに確かめておくと次の一手が決まります。講義では5つの問いで確かめていますが、ここでは3つを挙げます。「AIに質問したことがある」「複数のAIを使い分けている」「自動で動いている仕事がある」。順に答えて、Yesが続く最後が今の位置です。報告スライドの実験は、「一緒に作る」から「任せる」へ進むための、いちばん小さな一歩になります。
僕はエンジニア経験ゼロのまま、自分で設計図を書き、AI経営本部を48時間で組み上げました。設計図を書くのも、AIに渡す前に、何をどの順でやるかを言葉で決める作業です。
僕なら、評判の機能を見たら、まず自分の仕事から1本だけ選び、時間という1つの数字で判断します。良ければ2本目に広げる。合わなければ、別の仕事で試す。AIは、使うものではなく、育てるもの。今週の報告スライド1本から、育て始めます。
