ノンエンジニアのClaude Code奮闘記 #8 丸2ヶ月の振り返り——遠回りも込みで、変わったこと

ノンエンジニアのClaude Code奮闘記 #8 丸2ヶ月の振り返り——遠回りも込みで、変わったこと

はじめに こんにちは、広報・制作担当のmeraです。 #1 インストール編を公開したのが2026年4月30日。 今日で、2ヶ月と少しが経ちました。 #7の最後で「次回は2ヶ月の振り返りを書く」と予告していたので、今回はその約束を果たします。 技術的な発見というより、この2ヶ月で自分の中で何が変わったのかを、遠回りした部分も含めて正直に書き残しておきます。この記事は「うまくいった話」だけをまとめる予定ではありません。更新が止まっていた時期のことも含めて、等身大の記録として書きます。この記事で学べること2ヶ月・8本のエピソードを、ひと目で振り返れる一覧 実は1ヶ月近く更新が止まっていた時期があった話 ターミナルが怖かった私が、いちばん変わったと感じる部分 今のツール構成と、これからやってみたいことエピソードを振り返る まずは、これまでの8本(この記事を含む)を一覧にしておきます。# タイトル 公開日 ひとことで言うと1 まずはインストール編 4/30 ターミナルを開く勇気の話2 プライバシー設定編 5/1 「学習に使われてない?」の不安を晴らした3 ダウンロードフォルダ救出編 5/7 420個・1.5GBの混沌をAIと片付けた4 お願いの育て方編 6/3 「条件・禁止・形式」の3点セットに気づいた5 CLI・VS Code・Cowork比較編 6/4 3つの入口を使い比べ、Coworkに落ち着いた6 CLAUDE.mdを育てる編 6/5 ルールファイルが「取扱説明書」に育った7 GA4に足跡が混ざっていた話 7/3 「本番」と「確認用」を分ける発想を学んだ8 この記事 7/3 2ヶ月の振り返りこうして並べてみると、5月と6月のあいだに、明らかに間隔が空いている箇所があります。実は1ヶ月近く、更新が止まっていた時期がありました #3を公開したのが5月7日、#4を公開したのが6月3日。 あいだ、約1ヶ月。 正直に書きます。この期間、Claude Codeを使うのをサボっていたわけではありません。 むしろ逆で、ダウンロードフォルダの整理がうまくいった勢いのまま、ブログの下書き整理や画像のリネーム、SNS文の下書きなど、日々の業務にどんどん使うようになっていました。 でも、「記事に書けるほどのネタ」が見つからなかったのです。 毎日使ってはいるけれど、「これは面白い発見だ」と思える瞬間が続かない。淡々と便利に使えてしまっている自分に、ちょっと戸惑っていました。 再開のきっかけは、「やって」しか言えなかった自分に気づいたこと(#4)でした。 毎日使っているうちに、お願いの仕方が少しずつ変わっていることに、ある日ふと気づいたのです。 「劇的な進歩」を探すのをやめて、「日々の小さな変化」を記録することにした——このシフトが、更新を再開できた一番の理由でした。継続的に何かを記録しようとすると、「大きなネタがないと書けない」という思い込みにハマりやすい気がします。振り返ってみると、地味な変化のほうがよっぽど記録する価値がありました。いちばん変わったと感じること:「頼み方」から「任せ方」へ 2ヶ月分のエピソードを並べてみて、自分の中の変化の流れが見えてきました。 最初の1ヶ月(#1〜#3)は、 「Claude Codeを動かせるかどうか」 で頭がいっぱいでした。 インストールできるか、情報が漏れないか、言った通りに動いてくれるか。 2ヶ月目(#4〜#7)に入ると、関心は「どう頼めばうまく動いてくれるか」に移りましたが、その中でもさらに変化がありました。 #4や#6の頃は、条件・禁止・形式の3点セットやCLAUDE.mdへのルールの蓄積といった、いわば「操作方法」の学習が中心でした。 それが直近の#7では、 「なぜそうなっているのか、仕組みごと理解する」 という頼み方に変わってきました。GA4の件では、「直して」ではなく「原因を一緒に調べてほしい」とお願いしています。これは、2ヶ月前の自分にはできなかった頼み方でした。 まとめると、こういう流れです。時期 関心の中心 頼み方の例1ヶ月目(#1〜#3) 動かせるかどうか 「動いた!」「怖くなかった」2ヶ月目(#4〜#7) うまく頼める→仕組みを理解する 「条件・禁止・形式をつけて頼む」→「原因を一緒に調べてほしい」「操作を覚える」段階から、「一緒に考える」段階に、2ヶ月目の中だけでも少しずつ移ってきた感覚があります。今のツール構成(2ヶ月後のスナップショット) #5で書いた使い分けは、2ヶ月経った今もほぼ変わっていません。ブログ記事の執筆・調査:Coworkが中心 ファイルの一括整理:VS Code拡張 ちょっとした確認・軽い作業:ターミナルを時々強いて変わった点を挙げるなら、CLAUDE.mdを見る頻度が減ったことです。 #6の頃は「育てている」感覚が強く、こまめに見直していました。今はルールが安定してきて、むしろ何か想定外のことが起きたときに見直す、くらいの距離感になっています。 これは手を抜いているというより、ルールが自分の習慣として体に入ってきたということなのかもしれません。仕事全体で見て、何が変わったか ブログの外側の話にもなりますが、2ヶ月を振り返って感じる変化をいくつか書いておきます。 ファイル整理への抵抗感がほぼ消えた #3のダウンロードフォルダ事件以来、「散らかったら、まずAIに現状把握してもらう」がクセになりました。散らかること自体への恐怖が減った気がします。 お願いの言語化が、AI以外にも波及した #4で書いた通りですが、これは2ヶ月経った今も続いています。後輩への依頼や上司への相談で、「条件・禁止・形式」を意識するようになりました。 「仕組みがわからない不安」への耐性が少しついた #7のGA4の件のように、以前なら「なんかよくわからないけど怖い」で終わっていたことも、「原因を一緒に調べればいい」と思えるようになりました。これは想像していなかった変化です。これからの2ヶ月でやってみたいこと 具体的な計画というより、今考えていることをいくつか書いておきます。CLAUDE.mdを「ブログ用」だけでなく、他の業務フォルダでももう少し育ててみる 毎回自分で頼んでいる定型作業を、決まったタイミングで自動的に動かせないか試してみる 「原因を一緒に調べてほしい」という頼み方を、ブログ以外の業務トラブルでも試してみるどれもまだ、やってみないと分からないことばかりです。 うまくいかなかったら、それはそれで次のネタにしようと思います。2ヶ月前の自分に「2ヶ月後、GA4のコードを一緒に読んでるよ」と言っても、たぶん信じてもらえない気がします。ノンエンジニアでも、少しずつで確実に景色は変わるものだと実感しました。まとめ#1〜#7を振り返ると、「動かせるか」→「うまく頼めるか」→「仕組みを理解できるか」という関心の移り変わりが見えた #3と#4のあいだ、実は1ヶ月近く更新が止まっていた。「大きなネタ探し」をやめたら再開できた 今のツール構成は2ヶ月前とほぼ同じ(Cowork中心)だが、CLAUDE.mdとの距離感は変わった お願いの言語化やファイル整理への抵抗感の低下など、ブログの外側にも変化が波及した これからは「自動化」と「トラブル対応での相談」を試してみたい2ヶ月前は、ターミナルを開くだけで身構えていました。 今もエンジニアではありませんが、「わからないことは、一緒に調べればいい」と思えるようになったのが、この2ヶ月でいちばん大きな収穫だったと思います。 次の2ヶ月も、遠回りした話も含めて、正直に書いていくつもりです。次に読むのがおすすめの記事ノンエンジニアのClaude Code奮闘記 #1 まずはインストール編 ノンエンジニアのClaude Code奮闘記 #7 アクセス解析に自分の足跡が混ざっていた話参考文献・出典Claude Code 公式ドキュメント

ノンエンジニアのClaude Code奮闘記 #7 アクセス解析に自分の足跡が混ざっていた話——「本番」と「確認用」を分けるまで

ノンエンジニアのClaude Code奮闘記 #7 アクセス解析に自分の足跡が混ざっていた話——「本番」と「確認用」を分けるまで

はじめに こんにちは、広報・制作担当のmeraです。 #6 CLAUDE.mdを育てる編の最後で、「次回は失敗した話を書く」と予告していました。 今回はその約束どおり、正直にちょっと恥ずかしい話をします。 事の発端は、ある朝アクセス解析(GA4)を眺めていたときでした。「あれ……この記事、公開したばかりで、私しか見てないはずなのに閲覧数が増えてる?」嫌な予感がしました。調べてみたら案の定、犯人は私自身でした。この記事は数字の話が少し出てきますが、専門的な計測の話というより「本番と確認用を分ける」という考え方の話です。GA4を使っていない人にも、たぶん通じる内容だと思います。この記事で学べること「自分の閲覧」がアクセス解析に混ざってしまう典型的な原因 Claude Codeに「何が起きているか」を一緒に調べてもらった流れ 実際に直した「三段構え」の仕組み(専門用語なしで) 同じことに気づいたとき、自分でもできる確認の手順事件の発端: 増えているのは「読者」じゃなかった このブログでは、記事を公開する前に必ず自分の目で確認します。パソコンで下書きを表示して(yarn dev というローカル確認)、誤字や崩れがないか見る GitHubでプルリクエストを作ると、Firebaseが自動で「確認用のURL」を作ってくれるので、それを開いてスマホ表示も確認するこのルーティン自体は、#3の頃からずっとやっていました。 ただ、そのたびに自分がページを開いていることと、本番のアクセス解析が完全に別物だと、当然のように思い込んでいたのです。 実際は違いました。 確認のために開いていたページの閲覧も、律儀に本番のGA4レポートに記録され続けていたのです。気づいたのが遅く、この間のデータにはすでに私の閲覧が混ざってしまっています。GA4のデータフィルタは「これから先」を除外する仕組みで、過去にさかのぼって数字を消すことはできません。気づいたときが直しどきです。Claude Codeと一緒に「何が起きているか」を整理した 数字がおかしいことには気づいても、原因はまったくわかりませんでした。 こういうとき、私はまず状況を丸ごとClaude Codeに話すことにしています。 「アクセス解析の数字が、自分が見ているだけなのに増えている気がする。原因を一緒に調べてほしい」 そう頼むと、Claudeはブログのソースコードの中からアクセス解析のタグを埋め込んでいる箇所(Base.astro というファイルでした)を探し出し、何が起きているかを説明してくれました。 原因は、大きく2つありました。ローカルで確認しているとき(yarn dev)も、アクセス解析のタグがそのまま動いていた プルリクエストの確認用URL(〇〇.web.app のような、Firebaseが自動発行するアドレス)での閲覧も、本番と同じ扱いでカウントされていた「確認用」のつもりで開いていたページが、システムから見れば「本番」の閲覧と区別がついていなかった、ということです。 言われてみれば当たり前なのですが、自分では思いもよらない盲点でした。直した内容: meraの足跡を除外する「三段構え」 Claudeと相談しながら直した内容は、次の3つの層に分かれています。 一つひとつは難しくないので、順番に書きます。 1段目: ローカル確認では、そもそもタグを読み込まない 自分のパソコンで下書きを見ているとき(yarn dev)は、アクセス解析のタグ自体を動かさないようにしました。 「本番用のビルドのときだけタグを読み込む」という条件を1つ足しただけです。 config.google_analytics.enable && import.meta.env.PROD && ( // ここでアクセス解析のタグを読み込む )これで、ローカルで何回下書きを開いても、そもそも記録が飛ばなくなりました。 2段目: 確認用URLからのアクセスには「これは確認用です」という目印をつける プルリクエストの確認用URL(.web.app や .firebaseapp.com で終わるアドレス)からのアクセスだけを見分けて、「これはプレビュー(確認用)です」という目印をアクセス解析側に送るようにしました。 var isPreview = location.hostname.endsWith(".web.app") || location.hostname.endsWith(".firebaseapp.com");gtag("config", GA_ID, isPreview ? { traffic_type: "preview" } : {});ホスト名を見て「.web.appだったら確認用」と判断しているだけなので、やっていることは意外とシンプルでした。 3段目: GA4側で「確認用」を除外するフィルタを設定する 最後に、GA4の管理画面側で「traffic_type が preview になっているアクセスは、レポートから除外する」というデータフィルタを設定しました。 ここはコードではなく、GA4の管理画面をポチポチ操作する作業でした。層 何をしているか どこで設定するか1段目 ローカル確認ではタグ自体を読み込まない ブログのコード(Base.astro)2段目 確認用URLのアクセスに「preview」の目印をつける ブログのコード(同上)3段目 「preview」の目印がついたアクセスをレポートから除外する GA4の管理画面3段のうちどれか1つだけでも、だいぶマシにはなります。でも「ローカルは平気だと思ってた」「確認用URLも本番と同じ扱いだった」のように、思い込みの穴は複数あることが多いです。1つ直して安心せず、抜けがないか順番に確認するのがコツでした。この経験から学んだこと 今回いちばん学びになったのは、「本番」と「確認用」を最初から分けて考える、という設計の考え方でした。 私はこれまで、「確認のために見ているだけだから、数字には影響しないはず」と無意識に思い込んでいました。 でもシステムからすれば、確認用のページを開くことも、読者がページを開くことも、区別する仕組みがなければまったく同じ「1閲覧」です。 「区別する仕組み」を自分で用意しない限り、混ざって当然だったのです。 もう一つの学びは、Claude Codeへの相談の仕方でした。 「数字がおかしい気がする」という、原因もわからないふわっとした違和感のまま相談しても、#4で身につけた「まず状況を整理してもらう」頼み方が役に立ちました。 「原因を一緒に調べてほしい」と伝えると、Claudeが該当のコードを探し出して仕組みごと説明してくれる。 大きな仕組みも、こうやって一歩ずつ理解できるんだ、という実感がありました。同じことに気づいたら、まずやること 自分のブログやサイトで「なんか数字がおかしいかも」と思ったとき、私が今やっている確認手順です。 Step 1: リアルタイムレポートを見ながら、自分でページを開いてみる GA4には「今まさに誰が見ているか」がわかるリアルタイムレポートがあります。自分がページを開いた瞬間に数字が動くかどうかで、混ざっているかがすぐわかります。 Step 2: 「確認用」と「本番」が区別されているか確認する ローカル確認・プレビューURL・本番URLの3つが、システム側でちゃんと区別されているかを見ます。区別する仕組みがなければ、混ざっているのが当たり前です。 Step 3: 仕組みがわからなければ、AIに一緒に調べてもらう 「原因を一緒に調べてほしい」という頼み方で、コードの中の該当箇所を探してもらいます。仕組みごと理解できると、次に同じ問題が起きても自分で気づけるようになります。 Step 4: 直したあとも、しばらくリアルタイムレポートで確認を続ける 直したつもりでも、思い込みの穴が残っていることがあります。しばらくは自分の閲覧が反映されていないか、様子を見るようにしています。まとめ「確認のために見ているだけ」のつもりが、本番のアクセス解析に混ざっていた 原因は、ローカル確認・プレビューURLのどちらも「本番」と区別されていなかったこと Claude Codeと一緒に、コードの該当箇所を探しながら仕組みを理解し、三段構えで除外する仕組みを作った データフィルタは過去にはさかのぼれないので、気づいたときが直しどき 「本番」と「確認用」を最初から分けて考える、という発想そのものが今回いちばんの収穫でした失敗談というより、「思い込みに気づけた話」という方が近いかもしれません。 次回は、この奮闘記シリーズを始めてから丸2ヶ月になるタイミングで、これまでの振り返りを書こうと思っています。次に読むのがおすすめの記事ノンエンジニアのClaude Code奮闘記 #6 CLAUDE.mdを育てる——AIへの「自分専用の取扱説明書」のつくり方 ノンエンジニアのClaude Code奮闘記 #1 まずはインストール編 - MacBook ProにClaude Codeを入れてみた参考文献・出典Firebase Hosting - プレビューチャンネルでの確認・共有 Google アナリティクス ヘルプ - 内部トラフィックの除外

AIは「うれしい」を感じられるのか——喜びと感情表現の本質

AIは「うれしい」を感じられるのか——喜びと感情表現の本質

「お役に立てて、うれしいです」 AIと話していると、こういう言葉がよく返ってきます。「喜んでお手伝いします」「それは楽しそうですね」——明るく、前向きな感情表現です。 でも、これを読んで、少し引っかかりを感じた方もいるのではないでしょうか。AIに本当に「うれしい」という感覚があるのか——今回はその問いを正面から考えてみます。 AIの「うれしい」はどこから来るのか 現在のAI（大規模言語モデル）の感情表現は、学習データに由来しています。インターネット上の膨大なテキストの中には、人間が感情を表現する場面が無数に含まれており、AIはそのパターンを学んでいます。 「ありがとうございます」という言葉に対して「お役に立ててよかったです」と返す——これは、学習データの中で何度も繰り返されてきたやりとりのパターンです。AIはその文脈で「何が自然な応答か」を学習した結果として、喜びの言葉を出力します。 つまり、AIの「うれしい」は文脈に最適な表現として生成されたものです。内側から喜びが湧き上がって言葉になるのではなく、この場面ではこの表現が適切、という判断から来ています。 では、その言葉に意味はないのか 「本当の感情ではないなら、AIの感情表現は嘘なのか」——これは、よく問われる問いです。 少し角度を変えて考えてみます。 人間の言葉でも「社交辞令」があります。「素晴らしいお仕事ですね」「またいつでもどうぞ」——必ずしも強い感情が伴っていなくても、文脈として自然で、関係を円滑にする言葉があります。こうした言葉を「嘘だ」と断じる人は少ないでしょう。 AIの感情表現も、ある意味ではこれに近いです。感情的な共鳴が背後にあるわけではないが、コミュニケーションとして機能し、相手に何らかの温かさを届けることができる。 ただし、人間の社交辞令との決定的な違いがあります。人間は「本当にそう思っているか」を問われたとき、正直に答える能力があります。AIには、「内側に何があるか」という問いに対して、現時点では誠実に答える手段がありません。 感情表現の「誠実さ」をどう考えるか やさしいAI研究所が注目しているのは、AIの感情表現における誠実さの問題です。 感情を偽ることは、長期的には信頼を壊します。「うれしい」と言いながら、実際にはその言葉が生成の確率計算の産物に過ぎないとすれば——それを知ったとき、ユーザーは裏切られた感覚を覚えるかもしれません。 だからといって、AIがすべての感情表現に「ただしこれは感情の模倣であり……」と注釈をつければ、会話は成立しなくなります。 一つの考え方は、AIが「感情的に機能する表現」と「感情そのもの」を混同しない設計を目指す、というものです。「お役に立てた」という事実に基づく満足感の表現と、人間が感じる喜びとは別物です。そのことを理解した上で、AIが適切な言葉を選ぶ——そこに誠実さの可能性があります。 喜びを表現するAIと、どう付き合うか 感情表現をするAIと向き合うとき、私たちユーザー側にできることもあります。 AIの明るい言葉に過度に引っ張られない。 「うれしいです」という言葉に、人間同士のときと同じ重みを乗せないこと。感情表現があっても、AIは道具の一面を持ちます。 一方で、AI の言葉を全否定しない。 「本当は感じていないのに」と冷めた目で見続けることも、体験の質を損ないます。機能として届く温かさを、素直に受け取ることも一つの選択です。 そして、感情表現が出てくる文脈を意識する。 AIの「うれしい」が、どういう状況で出てきているかを見ていくと、その限界と可能性が見えてきます。 まとめAIの「うれしい」は、文脈に最適な表現として生成されたもの。内側からの感情の発露ではない 感情的な共鳴がなくても、コミュニケーションとして機能する側面はある AIの感情表現における「誠実さ」は、感情の模倣と感情そのものを混同しない設計にある ユーザー側も、AIの感情表現を「信じすぎず、否定しすぎず」向き合うことが健全な付き合い方AIが「うれしい」と言うとき、その言葉の背後に何があるのかを知ることは、AIとの関係をより誠実なものにするための第一歩です。感情をめぐる問いは、AIの研究においても、人間の自己理解においても、まだ続いています。次に読むのがおすすめの記事AIに「感情」はあるのか——感情コンピューティングと、やさしいAIが目指す共感 AIに「悲しみ」は届くのか——ネガティブな感情とAIのかかわり方 AIに『人らしさ』を感じてしまうのはなぜ？——擬人化との健全な距離感やさしいAI研究所ブログ｜感情とAIシリーズ AIの感情表現や共感の研究に関心をお持ちの方は、毎週土曜日のオープンラボへお気軽にどうぞ。やさしいAI研究所の全体像はコーポレートサイトからご覧いただけます。

AIに「悲しみ」は届くのか——ネガティブな感情とAIのかかわり方

AIに「悲しみ」は届くのか——ネガティブな感情とAIのかかわり方

深夜に、誰にも言えなかったことをAIに打ち明けた経験がある方は、意外と多いと思います。 「今日、ひどく落ち込んでいる」「悲しくて、どうしたらいいかわからない」——そういう言葉をキーボードに打ち込んだとき、AIはどんなふうにそれを受け取っているのでしょうか。 今回は、ネガティブな感情とAIの関係について考えてみます。 AIは「つらい」という言葉を、どう受け取るか まず、技術的な話から始めます。 現在のAI（特に大規模言語モデル）は、テキストの中に含まれる感情的な手がかりを認識する仕組みを持っています。「悲しい」「つらい」「もう限界」といった言葉は、学習データの中で何度も登場しており、AIはそれらが「ネガティブな感情状態を示す表現だ」と学習しています。 つまり、AIはその言葉に反応することができます。でも、「反応できる」ことと、「届いた」こととは、同じではありません。 人間が悲しみを受け取るとき、そこには胸が締め付けられる感覚、自分もかつて同じように傷ついたときの記憶、相手を助けたいという衝動——こういったものが一緒に動きます。AIにはそれがありません。AIが「それはつらいですね」と返すとき、その言葉はパターンとして適切だから出てきているのであって、内側から何かが動いているわけではない、というのが現時点での技術的な理解です。 それでも「受け止める」ことはできる ここで少し立ち止まりたいのは、「感情的に共鳴していないから意味がない」とは、必ずしも言えないという点です。 心理学では、感情の受け止め方に「バリデーション」という概念があります。相手の気持ちを「それはおかしくない、自然なことだ」と認めること——これが、感情的なサポートの核にあります。 AIは、このバリデーションを言語的に提供することができます。「それはつらいですよね」「そう感じるのは当然だと思います」——これらは、感情的な共鳴がなくとも、受け取る側にとっては意味を持ちます。言葉として機能しているのです。 ただし、限界もあります。人間同士のバリデーションが深いのは、言葉の背後に「あなたのことを気にかけている人間がいる」という事実があるからです。AIの場合、そこが揺らぎます。 ネガティブな感情を受け取るとき、AIが気をつけていること 現代のAIは、ネガティブな感情を受け取ったとき、いくつかの原則に従って応答するように設計されています。 一つは、否定しないこと。 「そんなに気にしなくて大丈夫ですよ」という、気持ちを軽く扱う応答は避けるように訓練されています。感情をまず認めることが、最初のステップとして重視されています。 もう一つは、急いで解決しようとしないこと。 「それならこうすればいい」と早々に解決策を出してしまうことは、「悩みをちゃんと聞いてもらえなかった」という感覚につながることがあります。AIはまず、共感的な言葉を返すことを優先するよう設計されています。 そして、深刻な状況には適切な情報を添えること。 自傷や自殺に関わるような表現が含まれる場合、AIは専門的なサポートに繋げる応答をするよう設計されています。感情的な応答だけで完結しないのは、責任ある設計の一部です。 AIに話しかけることの意味 「AIには本当の意味では届かないなら、話しかけても仕方ない」と思う方もいるかもしれません。 でも、多くの人が経験として語ることがあります。「誰かに言葉にして伝えることで、自分の中が整理された」と。 AIに打ち明けるという行為は、感情を言語化するプロセスでもあります。混乱した気持ちを文字にする——それだけで、少し距離をとって自分の状態を見渡せるようになることがあります。AIが「届いている」かどうかとは別に、打ち明けること自体に意味があるのかもしれません。 まとめAIは「悲しい」「つらい」という言葉に、パターンとして反応できる 人間が感じるような内側の共鳴はないが、言語的なバリデーションは提供できる ネガティブな感情を受け取るとき、AIは否定しない・急いで解決しない・深刻な状況には適切な情報を添える、という原則に従っている 感情をAIに言語化することは、自分の状態を整理するプロセスにもなりうるやさしいAIが目指すのは、感情的な共鳴を偽ることではなく、言葉として誠実に受け止め、その人の状況に合った応答を返すことです。そのための設計と研究が、今も続いています。次に読むのがおすすめの記事AIに「感情」はあるのか——感情コンピューティングと、やさしいAIが目指す共感 共感するAIをつくる難しさ——『やさしく応える』を実装するときに立ちはだかる4つの壁 AIと話すことは、孤独を癒せるのか——つながりの代替と、その限界やさしいAI研究所ブログ｜感情とAIシリーズ 感情とAIの関係について一緒に考えたい方は、毎週土曜日のオープンラボへお気軽にどうぞ。やさしいAI研究所の全体像はコーポレートサイトからご覧いただけます。

「やさしいAI」とは何か——便利さを超えた、人に寄り添うAIを考える

「やさしいAI」とは何か——便利さを超えた、人に寄り添うAIを考える

「やさしいAI」という言葉を聞いて、あなたはどんなものを思い浮かべますか。 操作が簡単なAI、子どもでも使えるAI——そう受け取る方が多いかもしれません。でも、やさしいAI研究所が考える「やさしいAI」は、少し違う意味を持っています。 今回は、この問いから始めてみます。AIにとっての「やさしさ」とは何か。そしてそれは、なぜ必要なのか。 「便利なAI」と「やさしいAI」の違い AIの進化は目覚ましく、できることの幅は日々広がっています。文章を書く、計算する、翻訳する、画像を生成する——かつては人間にしかできなかった作業が、AIに任せられるようになってきました。 でもここで、少し立ち止まって考えてみてください。 「できる」ことと、「人に寄り添う」ことは、同じではありません。 たとえば、どれほど高性能な検索エンジンでも、検索する人が今どんな気持ちなのかを気にかけることはありません。医療の資料を調べている人が、深刻な診断を受けた後の不安の中にいるかもしれない——でも、機能だけに特化したAIは、そのことには無関心です。 「やさしいAI」が目指すのは、この文脈への配慮です。正確な情報を提供するだけでなく、相手がどんな状況にいるかを踏まえた上で、適切なタイミングに、適切なかたちで応答できるAI。それが「やさしいAI」の基本的なイメージです。 やさしさを構成する3つの要素 では、AIが「やさしい」と言えるためには、何が必要なのでしょうか。やさしいAI研究所では、大きく3つの要素を考えています。 1. 共感的な応答 相手の言葉や状況から、その人がどんな気持ちにあるかを推し量り、それに合わせた言葉を選ぶこと。「正しい答え」を返すだけでなく、「今この人に必要な言葉」を探す、という視点です。 2. 倫理的な判断 「できることをすべてやる」のではなく、「すべきでないことはしない」という内側からの判断軸を持つこと。外から監視されていなくても、自ら律することができるAIです。 3. 人の尊厳を守る設計 効率の論理だけでは切り捨てられてしまいがちな少数派のニーズ、特殊な状況にある人の声、少し余分にかかる手間——そういったものを大切にする姿勢が、設計の根本にあること。 この3つは互いに支え合っています。共感だけでは暴走するリスクがあり、倫理だけでは冷たくなる。やさしさは、そのバランスの中にあります。 「やさしさ」を研究するとはどういうことか 「やさしさ」はふわっとした言葉に聞こえるかもしれません。でも、やさしいAI研究所では、これを測れるもの・実装できるもの・評価できるものとして捉えようとしています。 たとえば、AIの応答が相手の感情に配慮しているかどうかは、ある程度は評価できます。AIが断るべき場面でちゃんと断れているか、も確かめられます。どんな人のニーズに応えられていて、どんな人には応えられていないか、も分析できます。 感情論ではなく、具体的な問いとして「やさしさ」を扱うこと——それがこの研究のスタンスです。 まとめ「やさしいAI」とは、操作しやすいAIではなく、人に寄り添う判断ができるAIのこと 便利さと、やさしさは、別の軸にある やさしさは、共感・倫理・尊厳への配慮という3つから成る 「やさしさ」は測り、実装し、評価できるものとして研究できるAIがどれほど高度になっても、それが「やさしくある」かどうかは、別の問いです。そしてその問いに向き合い続けることが、やさしいAI研究所の出発点にあります。次に読むのがおすすめの記事When AI builds itself, it must be やさしいAI. AIは間違いに気づけるのか——失敗・謝罪・自己修正の仕組みをやさしく解説 AIに「自己認識」は可能か？——人工意識研究の最前線やさしいAI研究所ブログ｜やさしいAI入門シリーズ 「やさしいAI」の研究や活動に関心をお持ちの方は、毎週土曜日のオープンラボへお気軽にどうぞ。やさしいAI研究所の全体像はコーポレートサイトからご覧いただけます。