Your Brain on ChatGPT

わかっていたことではあるんだけど、論文が出ていたので紹介

Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task
https://arxiv.org/abs/2506.08872

要するに、LLMを用いることによって学習だとか認知みたいなものにどういう影響を与えるのか?という内容。

被験者としては下記の3グループに別れてエッセイを創作する

  1. 参考にLLMを使用することを許可されている
  2. 参考にWeb検索を使用することを許可されている
  3. 何も参考にせず、自分の頭だけで考える

これを3セット繰り返した後に、LLMの使用を許可していたグループには自分の頭だけで。自分の頭だけで考えていたグループにはLLMを許可して、その脳波などを計測して調べたということでした。

結果としては、LLMに頼っていたグループの神経接続パターンは弱く、エンゲージメントが低いという結果に。

結果としてこれは、なんとなく予想通りといえば予想通りだった。
自分の頭で頑張って考えていないので、出来上がったものに対しての理解も薄いし、再現性もない。
新社会人エンジニアがLLMが出してきたコードをなんの疑いもなく、動くのかどうかも確認せずにコミットしてくる情景が目に浮かぶようです。

ただ、それはLLMのせいなのか?と言われると、検索してQiitaか何かの記事を丸パクリして動かそうとしているのよりも、実際のところ良いコードがLLMから返ってくる事のほうが多い気もする。

それってエンジニアとしてどうなの?という疑問は生じてしまうけれど、アウトプットとしては手っ取り早い結果を生むことは出来そう。

それにLLMを用いて、その生成結果に対して疑問や質問を投げかけて試行錯誤するということもやり方としては十分検討の余地があって、その場合は脳波の結果もまた違ったものになるんじゃないかな、と思う。

そう考えると、これってそもそもどういう問題でだから何だっけ?という話になる。

結局のところ、道具をどう使うのか?という話であって、道具に使われちゃ駄目だよねって話に帰着するのではないかと思ってしまいますね。

組織におけるClaude利用検討

個人ではClaudeのProプランに課金していて、ProプランでClaudeCodeも利用できているので満足なのですが、仕事でも使いたい。

いや、正直全然使っていないわけじゃないんだけど大手を振って使いたい。

というわけで、検討してみた

セキュリティ・プライバシーに対する検討

デフォルトではClaudeへの入力データはモデル学習には使用されない

We will not use your Inputs or Outputs to train our models, unless: (1) your conversations are flagged for Trust & Safety review (in which case we may use or analyze them to improve our ability to detect and enforce our Usage Policy, including training models for use by our Trust and Safety team, consistent with Anthropic’s safety mission), or (2) you’ve explicitly reported the materials to us (for example via our feedback mechanisms), or (3) you’ve otherwise explicitly opted in to the use of your Inputs and Outputs for training purposes
https://www.anthropic.com/legal/privacy

上記プライバシーポリシーからは普通の使い方で明示的にAnthropicへデータ提供しない限りは学習データとして使わないとされている。

Teamプランによる運用

利用プランには、個人単位での利用を想定したProプラント最低5人からのTeamプラン。
そしてEnterpriseプランがある。個人のProの上位としてMaxがあるが、これは今回の対象からは考えない。

組織での運用を考えると、Proでミニマムスタートするか、Teamでスタートするかなんだけど、Teamプランの機能としてメンバーの追加・削除や利用状況の確認などの管理機能が提供される。

請求の管理も一元化されるので、組織で管理する場合にはやはりTeamプランが良さそう。

ただ、実験的に利用を開始する際には最低人数の5人というのが少し悩ましい数だなぁと正直思う。

月額で$30*5で考えると$150。145円位と考えると2万ちょっとか。
年契約すれば$25/月なので、1.8万ちょっと。

うーん、余裕で元が取れるんじゃないかなーと思うんですよね。
というか、悩んでいるのがバカバカしくなってきたな。。。

よし、週明け申請してみるか。

HBR 7月号

相変わらず読むのに気力がいるので時間がかかってしまうのですが、HBR7月号を読んだ

DIAMONDハーバード・ビジネス・レビュー20 2025年7月号 [雑誌]特集「リーダーらしさはどこから生まれるのか」 DIAMONDハーバード・ビジネス・レビュー

特集はリーダーらしさ。

リーダーとは?ではなくリーダー”らしさ”ってのがなかなか面白いテーマですね。

特集記事は4本あるのですが、アイデンティティマップを作成する。つまりは自分が何者なのかを知るという記事は色々と考えさせられた。

このアイデンティティマップみたいなもの。
結構リーダー研修とかでもよくやりますよね。
自分自身で作る場合もありますし、周りの人の協力を得て360度評価じゃないけれど、自分とはどんな人なのか?を認識する。周りからどういう評価を得ているかを理解する。

そういったことは自己形成において馬鹿にできない内容だと思います。

作ってみた

試しに、Claudeの助力を得ながらアイデンティティマップを作ってみました。

Claudeなので画像生成ではなくSVGで作られてしまい、ちょっと見づらいです。

問いかけをしてもらい、答えながら作るわけですが、自分自身で大事にしたいと思っていることが、最近、行動として実行できていないのではないか?と思ってしまった。

気持ちとしては、私は好奇心を持って動きたい。楽しいことがないかを探したいという人間で有りたいと思いながら、本当にそういうふうに動くことが出来ているのか?と。

もうちょっとコンフォートゾーンを出ていかないといけませんね

予期せぬ制限

ClaudeをProプランで課金して遊んでいるのですが、Claude codeを使ったあとでClaudeのチャットを投げかけると時々下記エラーが出るようになりました

具体的に何がどういう状態なのかはわからないですが、本来であれば使用制限に引っかかる前にアラートが上がるようですが、Claude codeの場合はそのまま通り過ぎてしまったのかもしれません。

そして、実際のところサーバー側が逼迫しているだけで直前にClaude codeを動かしていたこととは関係ないのかもしれません。

Claude Proには使用制限がありますか?
https://support.anthropic.com/ja/articles/8325612-claude-pro%E3%81%AB%E3%81%AF%E4%BD%BF%E7%94%A8%E5%88%B6%E9%99%90%E3%81%8C%E3%81%82%E3%82%8A%E3%81%BE%E3%81%99%E3%81%8B

このあたりは、ブラックボックスですね。
外からではさっぱりわかりません。

ただ、経験則としては10分程度待っていれば送ることが出来ているので、基本的に5時間の制限というものに引っかかっているわけではないと思っています。
とりあえず、落ち着けと言うのが現在のところなのでしょう。

トマト収穫

ようやくですが、大玉トマトが赤くなってきましたので収穫しました

大玉と言っても、小ぶりですね。

大玉トマトはそんなに多く実をつけるわけではないので、我が家の人数を考えると2苗ではなく人数分の苗を植えてしまったほうが良かったかもしれません。

それでも、久しぶりに大玉トマトがまともに実をつけました。
良かった。

収穫するときに、まだ緑色のトマトを見ると穴が空いていて、虫が入っている物がありました。
それ以外にもカラスにやられることもこれまであったり。

更には実が割れてしまうことも多いので、なにげにここまできれいに実をつけるのは久しぶりです。

もうすぐじゃがいもも収穫が可能になるかな~。
楽しみです

相手に対して期待をするべきか

どこで聞いたかは覚えていないが、「人に期待をしないほうがいい」という話を聞いた。
曰く、”期待”はする側が勝手にしているのであって一方的な押し付けになってしまう点をあげていた。

一方で、今読み進めている書籍では、ピグマリオン効果を引き合いに出して「積極的に期待をかけるべきだ」という論調が展開されていた。
書籍自体が、ちょっと疑問を感じる論調がいくつか見受けられるのでなんとも言いづらいけれど、ピグマリオン効果とゴーレム効果という話を考えると、わからなくもない話でちょっとモヤモヤした。

何が正しいというのは、結局のところ相手があっての話ではあるし、感情を持った人間である以上はどこかで期待してしまうのもしょうがないとは思う。

現実は思うようにいかない

実際のところ、私も部下に対して成長への期待をかけたことは何度もある。技術習得や勉強に対する意欲を高めてもらいたくて、「若いうちにしっかり学んでおいた方がいい」「将来のためになる」といった話をしてきた。

しかし、期待をかけたからといって、部下が急に勉強熱心になったりするとは限らないし、仕事以外での勉強などを強制するわけにもいかない。
ワークライフバランスを重視する価値観は決して間違っていないし、プライベートを充実させることで仕事にも良い影響をもたらすこともある。

そもそも、このあたりの話題は正直出しづらいことこの上なしなのは私が臆病なだけだろうか。

「期待」という言葉への違和感

「期待」という言葉そのものに問題があるのかもしれない。

期待には、どこか一方的なニュアンスがある。「こうなってほしい」「こうあるべきだ」という思いが前面に出てしまい、相手の意志や状況を十分に考慮できていない場合が多い。結果として、期待は相手にとって勝手なものとなってしまいがち。

また、期待には結果を求める側面が強い。「期待したのに応えてくれなかった」という失望につながりやすく、お互いにとって不幸な結果を招くこともある。

「後押し」というアプローチ

そこで私が辿り着いたのは、「期待」ではなく「後押し」というアプローチだった。

後押しとは、相手が一歩踏み出したくなるような環境やきっかけを提供することだ。結果を強制するのではなく、選択肢を示し、相手の意志を尊重しながら、成長の機会を作ることに重点を置く。

具体的には以下のような方法が考えられる:

情報提供の工夫 「勉強しろ」と直接言うのではなく、「参考までに」「興味があったら」という前置きで、セミナーや勉強会の情報を共有する。

成功体験の共有 先輩社員の成長ストーリーを自然な会話の中で話し、「こんな道もあるんだな」と感じてもらえるような機会を作る。

小さな成長の承認 些細な改善や努力も見逃さず、適切に評価する。自信がつくことで、次のステップへの意欲も生まれやすくなる。

環境整備 学習しやすい環境を物理的・制度的に整える。時間の確保、予算の手当て、上司としてのサポート体制など。

ここに上げたような内容を、Teamsに最近組み込まれたストーリーラインを使って勝手に垂れ流してみようと考えている。
大々的に周知しているわけではないのだが、徐々にそれらの土壌が作られてくるとそういった文化の情勢が出来るのではないかと考えている。

さてはて、どうだろうか。

相手のペースを尊重する

後押しのアプローチで大切なのは、相手のペースを尊重することだ。すぐに結果が出なくても焦らず、長期的な視点で関わり続ける姿勢が重要になる。

これは「期待しない」ということではない。むしろ、相手の可能性を信じているからこそ、時間をかけて丁寧に関わろうとする行為だ。一方的な期待とは質的に異なるアプローチと言える。
ただ、これを続けるのも難しいだろうなとも思う。
正直効果が見えないんですよね。

最後に

書籍を読みながらモヤッとしたところから考えを進めていって、とりあえず形にしてみたけれど、このアプローチが果たして良い結果につながるかはわからない。

とはいえ、特定の相手に対して直接発言する場面を作りつつ、ストーリーラインのように不特定多数に発言するという両面で進め、管理職として部下と向き合う上で、今後も「後押し」の質を高めていきたいと思う。

ずっと受けたかったソフトウェアエンジニアリングの新人研修

Audibleにあったので手にとって見た

ずっと受けたかったソフトウェアエンジニアリングの新人研修 第3版 エンジニアになったら押さえておきたい基礎知識

私自身、大学時代は情報系の学科を出たわけではなかったので、社会人になってからプログラミングを始めた口。
最初は周りとの差に苦労をしました。

自分自身がどういう新人研修を受けたかな?というと、社会人研修は受けたものの、ITの新人研修は入った会社には存在しませんでした。
配属された部署は、新人は私一人で他に開発をする人は二人だけ。そういう規模の部署だったので、新人研修なんてものがないんですよね。

しばらくは書籍をひたすら読んで学ぶということをしていた記憶があります。
(その後、集合研修みたいな形の体制に徐々に変わっていきましたが)

現在の会社でも今年の新人さんたちは新人研修を現在行っていて、7月から現場配属。
配属後は各現場での学習と実務が待っているわけです。

新人研修でどれくらい、何をやるのか?はぶっちゃけ会社によってものすごい違うと思います。
そもそも、どのレベルの新人が入ってくるのかが一番大きな落差が生じる部分だと思いますし、新人研修でどこまでのレベルに到達することを目指すのか?も大きく違いそうです。

自社のプロダクトやパッケージを持っている企業であればその技術スタックを中心とした研修になると思いますし、SESなどを展開している場合はJavaなど比較的ヒット率の高い技術を教える形なんだろうと思います。

本書では、それら技術に特化した研修ではなく、もっと一般的な。
ソフトウェア開発って何をするものなの?ということに重点を置いた教育になっています。

いわば、基本情報技術者試験的な感じがしました。

結構前まではこの辺の知識ってそれほど必要性を感じていなかったんですよね。
でも最近、文系出身だとかいろいろな新卒が入ってくる中で、このあたりの知識がないと共通言語がなくて会話が成り立たないな、と感じるようになってきました。

そういう意味では悪くはないのですが、これで新人研修を終えられると現場は大混乱するだろうなぁと思うのも事実。

何を持って新人研修を終えたとするのか。どこまでのラインまで行くことを目指すのかという、新人研修の要件があまりにも企業の余裕だとかによって変わっている現実がなんともしがたい、歯がゆさを残します。

結局、自社なりの教育カリキュラムを作るしかないようにも。
なんとも非効率な効率性ですね

この業界に絶望した!

プチ同窓会

大学時代の友人が、遠路はるばる富山からやってくるということで、同期や後輩も交えて11人ほどが集まり、同窓会的なものをやってきました。

大学時代のクラスメイト、そしてサークルの同期や先輩、後輩と良くもまぁ集まったものです。
20年ぶりくらいに会う人もいたりで、お互い時の流れを感じつつも変わらない部分は変わらないなぁと改めて思いました。

次にこのメンツが集まるのは一体いつになるのだろうか。

家庭が出来るとなかなかフットワーク軽く動くことが難しくなってしまいますが、友人は大切にしていきたいところです

プロンプトインジェクションに対する対策

Simonさんのブログで新たに発表された論文に対しての解説がされていた。
いつもお世話になっています

Design Patterns for Securing LLM Agents against Prompt Injections
https://simonwillison.net/2025/Jun/13/prompt-injection-design-patterns

エージェントを用いたシステム。
とりわけ、エージェント単体ではなくツールやMCPなどと組み合わせた時にはプロンプトインジェクションの危険性を考慮する必要性が生じてくる。

逆に言うと、LLM単体で用いるときには気にしなくていいのだろうか?

LLM単体と言っても、今のLLMは実質的にはWeb検索なども行ったりしてツールの利用がされることが多いことを考えるとうーんという気にもなる。

このあたりは、私のLLMに対する理解が足りてないから誤解を多く含んでいる可能性はある。

ソフトウェア開発においても、開発の手段としてエージェントが用いられることもあればシステムにエージェントを組み込む場面もどんどん出てくる。
このあたりのキャッチアップや認識、知識習得は目まぐるしく変わっていくこともあり非常に困難でコストがかかる。

覚えたことが数カ月後にはすでに過去の遺物になっているようなスピード感。
まさにこの学習にもLLMを使う必要が出てくる始末。

前提の確認を含めて、一度目を通しておかないとなぁと思いつつ、なかなか大変ですね

リハーサルは大事です

そこまで硬い話ではないのですが、会社で発表する必要があり、準備をしています。

私自身、こういう場で喋ること自体は苦手というわけではないのですが、ぶっつけで話ができるほどではないです。

スライドを作り、一応何を喋るかシナリオを書き起こし、リハやってみて時間を確認して、、って地味な動きですが、大事です。

シナリオを書いている段階ではあまり気にならないのですが、口に出してみると思ったように喋れていない。
さらに、なんか言っていることがうまくまとまっていない感じがする。

それらを調整しながら、シナリオを書き直す。
場合によってはスライドを調整する

そもそも誰に何を言いたいんだっけ?と立ち返るとまた調整が・・・

あれ、この発表ってそこまで準備に時間かけてやるほどなんだっけ?と思ってしまうと疑問が湧いてしまいますが、このあたりはしょうがないと割り切るしかないですね。

なんとかなるようやっていくしかありません。
頑張ろう