AIを使いこなすにはプロンプトが全て「生成ＡＩと脳: この二つのコラボで人生が変わる」(著者：池谷 裕二 2026年42冊目)

生成ＡＩと脳　この二つのコラボで人生が変わる (扶桑社ＢＯＯＫＳ新書)

仕事で生成AIを使う時間がかなり増えた。

文章を書く。
アイデアを出す。
資料を整理する。
プログラムを書く。
調べものをする。
自分の考えを壁打ちする。
・・・etc

今では、生成AIなしで仕事をすることを考えるほうが難しい。

2024年に出版された本で古いかなと思ったけど、生成AIそのものの説明だけではなく、「AIと人間の脳はどう付き合っていくのか」というところまで踏み込んでいて面白かった。

本書では、生成AIによって人間のすることがなくなるのではなく、むしろAIが人間の苦手なことを担うことで、人間は人間らしい行為に集中できる、というのは面白いなと思った。

この本を読んでいて、もう一つ感じたのが、

「AIを使いこなす」とは何なのか、ということだ。

生成AIの話になると、「プロンプトが重要」という話がよく出てくる。

もちろん、これは間違っていない。

しかし、本当の意味で重要なのは、プロンプトのテクニックだけではないと思う。

むしろ重要なのは、「自分は何をしたいのか」を明確にすることだ。

AI → 答えではなく、自分 → AI → 自分という循環が大事だと認識した。

本書では生成AIの歴史から、Gemini、Claude Code、ChatGPTのAIの性能にどれだけしのぎを削っているかもわかって面白い。

下記は本の紹介文だが、興味を持った方は一読をオススメします。

≪生成ＡＩがもたらす新しい脳の使い方！≫
◎空気が読めない人は、ＡＩを使うのも苦手
◎生成ＡＩは文系的な性質を持つ
◎クリエイティビティの面で勝てる人間は９・４%
◎上手なプロンプトを書くコツ
◎ＡＩに「意識」は存在するのか…
最新の知見をたっぷり解説！

「仮にＡＩなくして成立しない世界が訪れたとしても、人間が愚かになることは決してありません」著者

【目次】
第１章　生成ＡＩとは何か
第２章　人生を変える生成ＡＩを使いこなすスキル
第３章 「私」よりも「私」のことを知る存在
第４章　生成ＡＩが抱える10の問題
第５章 「新しい道具」がもたらす新しい脳の使い方
第６章　生成ＡＩは未来を導く「神」なのか？

【本書より】
ＡＩが存在するからといって、人間のすることがなくなるわけではありません。ＡＩに全てを任せることが、人間の生きる価値を否定することではないのです。むしろその逆で、人間にはＡＩではできない能力がたくさんあり、その価値は決して失われません。たとえば「楽しむ」という行為はその最たるものです。

さらに言えば、本来は人間が苦手なことをＡＩに任せ、自分たちは人間らしい行為に特化することで、「本来人間がするべきこと」に脳の使い方が特化されるはずです。

完璧な人間がいないように、完璧なＡＩも存在しないのです。

Claude Codeのプロンプトの書き方を振り返ってみました。※ClaudeCodeに文章を作成してもらいました

Claude Codeの話題は、どうしても環境構築に寄りがちです。

CLAUDE.mdをどう書くか、Skillsをどう切るか、subagentをどう定義するか。私自身も複数リポジトリにCLAUDE.mdとSkillsを整備して、それなりの型を作ってきました。

ただ、しばらく使い込んで分かったことがあります。

成果物の質を一番大きく動かしているのは、環境ではなく毎回打ち込むプロンプトそのものでした。

環境整備は「下限を上げる」作業で、プロンプトは「その日の上限を決める」作業なんですね。

この記事では、私が実際に使っていて効果が明確だった打ち方を6つに絞って共有します。

1．「目的・場所・完了条件」の3点セットで書く

結果が安定するプロンプトには、だいたいこの3つが揃っています。

【目的】
セッションタイムアウト後にログインが失敗する問題を直したい

【場所】
src/auth/ のトークンリフレッシュあたりが怪しい

【完了条件】
再現する失敗テストを書いてから修正し、npm test が通ること

対して、うまくいかないときの自分のプロンプトを見返すと、たいてい「ログインのバグ直して」だけです。

これだと、Claudeはまず問題箇所を探すところから始めることになり、探索でコンテキストを消費した末に見当違いの場所を触ることがあります。

3点セットは長く書く必要はありません。上の例も3行です。

2．完了条件だけは、絶対に省かない

3つのうちどれか1つを選ぶなら、迷わず「完了条件」です。

・テストが通ること
・ビルドがエラーなく終わること
・スクリーンショットが指定の画面と一致すること

こうした「機械的に検証できる条件」を渡すと、Claudeは自分でテストを回し、失敗を読んで直し、また回す、というループを回してくれます。

ここが人間の手離れの分岐点です。

逆に完了条件がないと、Claudeは「もっともらしいコード」を書いた時点で完了を宣言します。

3．探させずに、参照先を指定する

Claudeに探索させるのは、コンテキストという有限な資源を消費する行為です。

行き先が分かっているなら、最初から指してあげたほうが速くて正確です。

・ファイルを直接渡す
「@src/auth.js」と書けば内容が読み込まれます。

・既存パターンを指す
「HotDogWidget.phpを参考に、同じパターンでカレンダーウィジェットを実装して」

・履歴を指す
「ExecutionFactoryのgit履歴を見て、このAPIがどう変遷したか要約して」

3つ目は意外に使えます。

「なぜこの実装になっているのか」は、コードだけ読んでも分からず、コミットログに答えがあることが多いからです。

あわせて、指示は否定形より肯定形にします。

「モックを使うな」より「実際のDBに接続する統合テストで」。

何を避けるかより、何をしてほしいかを書いたほうが、出力のブレが小さくなります。

4．「一度に一つ」と「修正2回でリセット」

Claude Codeで一番効く運用ルールが、この2つです。

まず、「一度に一つ」。

1つのセッションでタスクAをやり、途中で別件Bを聞き、またAに戻る。

これをやると、無関係な情報がコンテキストに溜まって、肝心の指示が埋もれていきます。話題が変わったら「/clear」する。

それだけで精度が戻ります。

そして、もう一つが「修正2回でリセット」。

同じ箇所を2回直させても直らないとき、原因はたいていClaudeの能力ではなく、そのセッションが失敗例で汚染されていることです。

「さっきの間違い」の記憶が積み重なって、正しい方向に進みにくくなっている。

3回目の修正指示を打つ手を止めて、「/clear」してから、その2回で分かったことを盛り込んだプロンプトを新規に書く。

遠回りに見えて、体感では圧倒的にこちらが速いです。

5．重さに応じて、モードを使い分ける

すべてのタスクにPlan Modeを使う必要はありません。

私は次のように切り分けています。

1文で説明できる変更
→ typo修正、ログ追加など。Plan Modeを飛ばして直接依頼。

複数ファイルにまたがる、方針が固まっていない
→ Plan Mode → Ctrl+Gでプランを直接編集。

「〜がどうなっているか調査して」系
→ subagentに委譲。

設計判断・トレードオフの検討
→ プロンプトに「ultrathink」を明記。

subagentへの委譲は、慣れると手放せません。

調査で読み込んだ大量のファイルが本体のコンテキストに乗らず、要約だけが返ってくる。大きなリポジトリほど効きます。

Plan Modeで生成されたプランは、そのまま承認せず、Ctrl+Gでエディタを開いて手を入れるのがおすすめです。

ここで方針を1行直すコストと、間違った実装が終わってから直すコストは、桁が違います。

6．細かいけれど効く、2つのこと

「/compact」はフォーカス指示付きで。

素の「/compact」だと、残しておきたかった設計判断が落ちることがあります。

「/compact API周りの変更と実行したテストコマンドに絞って」

のように、何を残すかを毎回書く。

これだけでも、コンテキスト整理後の精度が変わります。

もう一つは、画像を惜しまないこと。

エラー画面、崩れたUI、参考にしたい図。

スクリーンショットを貼るだけで済むものを、言葉で説明しようとして時間を溶かしていた時期がありました。

貼ったほうが速いし、正確です。

まとめ

改めて並べると、こうなります。

1．目的・場所・完了条件の3点セットで書く
2．完了条件だけは絶対に省かない
3．探させずに参照先を指定する
4．一度に一つ、修正2回でリセット
5．重さに応じてPlan Mode・subagent・ultrathinkを使い分ける
6．「/compact」はフォーカス指示付きで、画像は惜しまない

どれも仕組みを作る話ではなく、「次の1回から変えられる打ち方」です。

CLAUDE.mdの整備は一度やれば効き続けますが、こちらは毎回の積み重ねで効いてきます。

個人的には、2の「完了条件」とを意識し始めてから、Claude Codeとの付き合い方がはっきり変わりました。

参考

Best practices for Claude Code
https://code.claude.com/docs/en/best-practices

Common workflows
https://code.claude.com/docs/en/common-workflows

Context management
https://code.claude.com/docs/en/context-window

他責思考だからうまくいく？「インド人は悩まない」(著者：インド麦茶 2026年41冊目)

インド人は悩まない: 「考えすぎ」から解放される究極の合理思考

オーディオブックで聞いてみました。

自分の利益のためなら、他人を利用する

富をひけらかす

身分の差によって、態度を露骨にかえる

他人の配慮は無用

言い訳と他責

・・・

一見すると、相容れない価値観のように思ってしまいがちですが、なぜにインド人はこのようなメンタリティーなのか？

という考察が書かれた本です。

前提として、私自身がインド人の友人がいるわけでもなく、現地に駐在しているわけではないので、真偽の程はわかりません。

ただ、気になったのは、こういった相容れない価値観の人とも、どう折り合いをつけて上手くやっていくかです。

極端な対応は、関係をもたないでしょうけど、それでは何も相互に発展や共存することはできません。

自分とは相容れない価値観に自ら飛び込み、まずは慣れてみるというのは、相手を理解するのに重要な振る舞いかもしれません。

本書のなかで気になったのが、他責思考について。

かなりの他責思考らしいのですが、どうやらそれは、あまりにもルールを守るといったソフト面や、密集・多民族・人口過多・極端な経済格差といった社会的インフラが未成熟が起因しているという仮説。

あまりにも不条理が横行している社会では、むしろ他責思考でないと前に進めないという意味だと、自分は理解しました。

そういった意味で日本の社会を考えれば、本人の行動の質と量次第で、変化を及ぼせる可能性がインドよりは高いことに、ありがたみを持つのもいいかもしれない。

必ずしも報われるわけではないが、自分の人生を好転されられる確率という観点で国を観察してみるのは面白いかもしれない。

インドは、もしかしら、自分の今持っている価値観を一度、破壊してくれる国かもしれず、そこに魅力を感じた人もいるかもと思いました。

一度は行ってみたいが、勇気がいりますね。

経営者を評価する方法を考えてみる

経営していて、自分のパフォーマンス評価を考えることがある。

何か定量的な指標があるといいと考えたときに、以下の4つが思い浮かんだ。

■売上高成長率

どれだけ事業を成長させたかがわかる

■営業利益率

本業の稼ぐ力を高めたか

■ROIC(税引後営業利益 ÷ 投下資本)

会社に投下された資本を使って、どれだけ利益を生み出したか

■営業CF

本業でどれだけ現金を生み出したか

社長を引き継いだら、上記４つの項目について過去3ヶ年の平均値を超えていたら最低条件はクリア、というのはどうだろう。

3ヶ年としたのは、たまたま今年だけ売上が伸びた、という偶発性を排除できる。

営業利益率としたのは、単純に営業利益額だと利益操作が及びやすいからだ。

例えば、毎年の広告費の計上月を翌期にずらしたりといった、テクニックは厳禁にしないといけないし、設備投資をするとその期は利益率が下がるから、未来3ヶ年平均の営業利益率とかで評価するのがいいかもしれない。

つまりは、過去3ヶ年と社長になってから先の3ヶ年との比較がいいのかもしれない。

ROICも投資した資本をきちんと利益を稼げる会社にしたかを測ることができる。

営業CFは本業での活動で継続的にプラスになっていないと赤信号だ。

その意味で、どれだけ現金を生み出しかは本当に重要だ。

自分のパフォーマンス評価を定量的にするために、こんな指標を考えてみました。

AIっぽさに嫌悪感が

AIがますます、日々の生活や仕事に影響を及ぼしている。

私も資料作成や分析を中心にAIを使わない日はないくらいだ。

先日はClaude Codeの月額利用限度額を達してしまい、追加課金をしてしまった。

仕事でのAIの使い方は、自社もだが他社も色々検討していると思う。

個人としての仕事活用だけではなく、どう組織としてAIを使っていくか。

あるシステム会社では、仕様書を作成したら、かならずAIのレビューを通すことを義務付けている。テストデータ作成やデグレテストなどは、AIの得意領域だ。

ますます効率がアップしていくだろう。

そんななかで、最近気になるのは、AIで作ったアウトプットをそのまま提出してくる場合だ。

それは提案資料だったり、分析レポートだったり、、、

「AIで作って、"ぽいっ"と渡してきたな」

と思うと、テンションが急激に下がる。

それはなぜか？

本人の理解を超えたアウトプットで、本人の"意思"がきちんと反映されていないものだからだ。

AIで作られたアウトプットに対して質問をしても、きちんと返せない。

そうすると、自分の頭で考えていないものを提出してきた。

それはつまり、その人が介在している意味がないと解釈している。

これを良しとする会社もあるかもだが、行き着く先は、何かあったときに、そのアウトプットに対して責任が取れない事態になる。

やはり、人間味のある、意思が入った成果物が欲しい。

AIの時代に逆行してしまっているが、自分のアウトプットに対しては、人間味は鮮明に残したい欲求が出てきました。

なので、ここ最近は逆行してアナログ化の方向へ向かっています。

他責NGの本質がわかってきた。それは自分が自分の主導権を持つことだ

以前、私が働いていたワークスアプリケーションズという会社では、「他責NG」が社訓として掲げられていた。

評価指標にも含まれており、社長も社員MTGなどで何度も口にしていた言葉だ。

当時の自分は、この言葉を「言葉として理解したつもり」になっていた。

とはいえ、変な言い訳をせず、目の前の仕事に全力で取り組んでいたことは間違いない。

ただ、今振り返ってみると、「他責NG」という言葉は、得てして間違った解釈をされやすい言葉だと思う。

例えば、自分が営業担当だとして、売上目標を達成できなかったとする。

そのとき、

「自分がすべて悪いのか？」と考えてみる。

会社の戦略や戦術に問題はなかったのか。

営業以前のマーケティングに問題はなかったのか。

上司の指示やマネジメントに問題はなかったのか。

……など、さまざまな原因が考えられる。

原因を正しく捉えようとしたときに、「すべて自分に原因がある」と自分を責めることは、「他責NG」の正しい解釈ではない。

むしろ、そう解釈してしまうことで、本質的な原因を捉えられなくなり、有効な対策を立てられなくなる。

結果として、問題はなかなか改善されない。

そして、「自分には実力がない」と、必要以上に自信を失ってしまう。これは、間違った「他責NG」だと思う。では、どう捉えればいいのか。

私は、

「自分ができることは何か？」

と考えることだと思っている。

例えば、

「会社が悪い」

「戦略が悪い」

「上司が悪い」

と、完全に他責にしてしまう。これは一見すると、自分を責めていないので楽に思える。でも、本当は逆だ。

「自分には何もできない」と考えてしまうことで、自分の行動する力を手放し、他者に自分の主導権を渡してしまっている。

だからこそ、

「会社の戦略に問題がある。では、その中で自分にできることは何か？」

「上司の指示に問題がある。では、自分から提案できることは何か？」

「マーケティングに問題がある。では、営業としてできることは何か？」

と考える。

これが、私が今考える「他責NG」だ。これまで仕事をしてきて、物事を前に進める人は、圧倒的に「他責NG」の人が多い。

もちろん、何でも自分の責任にするという意味ではない。問題の原因は冷静に分析する。そのうえで、

「じゃあ、自分は何ができる？」

と必死に考える。

否定や批判だけで終始していては、何も変わらない。自分の行動こそが、周りを変えていく。

この当たり前のことを、当たり前のこととして認識している人とは、仕事がしやすい。

もちろん、会社員であれば、

「そうはいっても……」

と言いたくなることがあるのも百も承知だ。

自分自身も、何度もそう思ってきた時期もある。けれど、そこから「自分ができることは何か？」を真剣に考え、実際に行動へ移してきた人は、言葉の重みが違うように感じる。

一方で、「他責にしない」ということが、自分自身を追い詰めることになってはいけない。もし、何もかも自分のせいにしてしまい、心が押し潰されそうになっている人がいるなら、まずは自分を否定しないでほしい。

ここまでやってきた自分を、十分に認めてあげてほしい。

そして、まずは一つずつでいい。

「自分の人生や仕事の主導権を、自分の手に取り戻す」

そんな意思を持ってみる。

少なくとも、自分で決めたことなら、誰かのせいにすることはないはずだ。

「なんで、他者に自分の主導権を委ねないとあかんねん！」

ぐらいの気概があってもいいと思う。

「他責NG」とは、自分を責めるための言葉ではない。

自分の人生や仕事の主導権を、他者に渡さないための言葉なのではないか。

そんなことを、今になって思いつき、つらつらと書いてみました。

波頭氏のAIを見通す慧眼が凄い「AIとBIはいかに人間を変えるのか」(著者：波頭亮 2026年40冊目)

ＡＩとＢＩはいかに人間を変えるのか (NewsPicks Book)

３年前に読んだ本ですが、今一度読んでみました。

AIの歴史から、今後AIがどのようになるのか？

この本が2019年に書かれた本ですが、現在のAIの進化に対する予測が驚くほど当たっていました。

また、何がAIができて、AIができないのかも、私が言語化するよりもはるかに的確に指摘しているところがすごい。

実のところ、AIの進化は人類にとってユートピアとなるのか、それともディストピアになるのか。

私は前者だと思っているけれど、今の社会制度ではAIの進化に合わせられなくなってきます。

極端な例でいえば、AIによって社長１人で事業が回せるようになった結果、資本家達の利益はますます増えていきます。

その一方で従業員は、退職を余儀なくされます。従業員も生きていくのに必死なので、AIではできない仕事（フィジカル的な仕事など）を探していきますが、だんだんと技術の進歩で、それすらもAIにとってかわっていく。。。

とすると、AIの恩恵を受けている人とそうでない人の差、つまりは経済格差が大きくなっていく。

今の社会が働くことを前提としている以上、人間がAIにできない仕事を創出し続ける運命にあるのかなと。

楽観的に考えれば、人が今のように働かなくても経済が回る仕組みが仕上がっていき、よりプライベートな時間を享受できるようになるかもしれません。

何にせよ、AIの進化に対して社会がどのように変化をしていくべきかは、資本主義社会に生きる人類にとって、重要なテーマであるのは間違いないです。