  |
はてなキーワード:プラクティスとは
※なんか頭のなかのもやを発露しただけの、駄文です。全部自戒です。
最近、生成AIの普及で質の低いコンテンツがめちゃくちゃ増えてる気がする。新しいツールやテクノロジーが出るたびに、表面的なチュートリアル記事が量産されて、検索結果がノイズだらけになってるよね。一部の専門家だけがアクセスできた情報を一般化すること自体は良いことなんだけど、問題は内容の薄さ。公式ドキュメントにAIで質問すれば、もっと適切で完璧な情報が得られる時代に、わざわざ劣化版のチュートリアルを作る意味ってあるのかね。
求められてるのは基本的なセットアップ方法じゃなくて、それらを使った独自の実践例や実験的な活用事例だと思う。そこにその人らしさや独自の価値が生まれるんだよね。
AI技術の進歩で、エンジニア界隈は今めちゃくちゃカオスな状態になってる。AIに批判的な既存エンジニア、AIコーディングを全面的に受け入れる層、AIによる新規参入者への反発、日々変わるベストプラクティス、短期間で陳腐化する専門性など、色んな思惑やイデオロギーが交錯してる。
それに、それぞれが住んでいる生態系やクライアントの特性、業界特性、背景、生まれた背景、国や言語なんかによって全然違うじゃん。例えば大企業がクライアントの場合は、当然そうじゃないところよりも色んな要素が多くなって複雑性が高い。一方で、そうじゃないところは煽り合戦だったりストーリーテリングみたいなのが大事だったりする。昔からよくある、ベンチャーvs大企業みたいな構図。だから、それぞれがいるポジションが全然違う中で、ああだこうだ言っても正直意味がない。そこで議論する前に、まずお前らのコンテクストをエンジアリングにしろよって思うわ。
生成AIブームで色んなプレイヤーが参入してるけど、現状を冷静に見ると面白い構造が見えてくる。今の生成AI界隈のプレイヤーって、大体初級レベルの情報商材・教育事業者、中級レベルの教育系AIサービス、生成AIを使った新規事業・起業家みたいな感じに分かれてる。この中で、生成AIネイティブで既存の業界課題を解決する形のサービスも一定数いるんだけど、圧倒的にやりやすくてレバレッジが効いて短期間で利益を取りやすいのは、まだAI利用の環境すら整っていないところの教育分野なんだよね。だから、そういったものへの参入が多い。想像したらわかりやすいけど、まだChatGPT使ったことない人に、ChatGPTの初級編の使い方を教える感じ。使った人はすげええええええってなるじゃん。
一方で、本当にAIや画像生成なんかを使ってユーザーを獲得して収益の上がるサービスを日本国内や海外向けに作っていこうとすると、そこには大きなハードルがある。そこにチャレンジしてる方々もいらっしゃるので、それは本当にリスペクトするし応援してる。なるべくサービスも使うようにしてる。でも、そうじゃない人の新規参入として、AIネイティブなサービスを作るのは本当に難しくて色んな変数があるので、プロダクションレベルで提供するのは困難。だからこそ参入が取りやすい教育系のサービスやコンテンツ販売、また今の時期だとAI動画を使ったYouTubeチャンネルみたいなところが参入しやすいので、そこのプレイヤーも多くなってしまう。エコシステムっていうのはこうして発展していく部分もあるけどさ、視座を高く持とうぜって。
そうすると、参入がしやすいものっていうのはあっという間に飽和してしまうので、そこに成功を求めて向かって行ってもあまり勝ち目がない。もちろん資本が大きい分には参入していって、そこのパイの一部をもらって売上を上げることができるかもしれないけど、微妙と言わざるを得ないかもしれない。何が言いたいかと言うと、AIを使ったネイティブなITサービス、純粋なITソリューション製品・サービスを作るっていうのは非常に難しい。BtoBの領域で言うと既存のワークフローがあったり業界特有の既存サービスがあったりするので、そういったもののプレイヤーたちがAIを組み合わせた方がむしろ効果が出やすかったりする。その業界ならではのAIサービスを0から作っていくような気概がないとそこは難しい。開発者向けのAIサービスっていうのは本当に世界中のエンジニアがある意味競合でもあり仲間みたいな状態なので、そこに挑戦する人々は本当に応援したい。
一方で、そうじゃない人の参入としては、やはり自分のバックグラウンドや強みもしくは隙間がある領域×AIみたいなところで勝負を探す方がいいんじゃないかと思う。その方が競合は少ないし独自の価値を付けやすい。それはWebサービスのみならず、自分のポジションやどの業界を見ようかって価値観の変容みたいなところも必要なんじゃないかと思うし、自分がどうすればレバレッジが効くのかみたいな観点でも有用になるのかなと思う。グローバルニッチって考え方がたびたび目にするけどそれだね。
あとは過去に投じた時間やお金への愛着が、変化の激しい時代では足かせになってしまう「サンクコスト」の概念は重要。これまでの思い込みや概念を一度見直す必要がある。これからは職種の細分化から「大統合」の時代になると考えてる。AIで一人ひとりのパフォーマンスが向上すれば、従来のような細かい職種分けじゃなくて、ビジネス系とバックエンド系、営業・マーケティングとエンジニアリングみたいな、もっと大きな単位での役割分担になるんじゃないかな。職がなくなるんじゃなくて、シフトするだけ。
個人で作る小さなサービスやアプリの多くは、既存のもので代替可能だよね。革新的に見えても、実際は誰かがやらなくても困らないものが大半。それよりも、たとえば日本独自の食文化や自然環境みたいな、時間をかけて積み重ねられた価値の方が、世界的に見てもユニークで重要だと思う。
ちなみに、インフルエンサーが作る情報商材についても思うことがある。彼らが何かコンテンツを作ったとしても、その情報はAIに聞くより古かったり、1ヶ月後には状況が全然変わってたりすることが普通にあり得る。そもそも作られた時点が半年前とかで、現在の状況とは全然違うってこともある。だから、そういうコンテンツに高いお金を払う前にAIに聞いた方がいいし、賞味期限が非常に短いってことは留意した方がいい。
良識のあるインフルエンサーやビジネスマンの人も言ってるけど、AIは自分が得意じゃない専門領域に掛け算して活用した方がレバレッジが効く。また、AIの情報を参考にするにしても、しょぼいティップスを紹介してる人をフォローするんじゃなくて、ちゃんとその業界の第一人者と言われる人たちを調べて、そういう人の評判も聞いて、それでフォローするべきだと思う。もちろん偏りすぎちゃダメだから、戦略的に複数のポジションの人たちをフォローしていくのは良いことだけど、偏りすぎたり変な信者みたいになってると、全く価値のない情報商材にお金を払ってしまって、結局コミュニティや情報商材の餌食になってしまうから注意が必要だね。
資本主義にはバグが多くて、短期的な利益追求が長期的な価値を破壊することがある。ダーウィンの進化論を誤用して「変化できるものが生き残る」って言う人がいるけど、実際は「多様な遺伝子を持つ集団の中で、たまたま環境に適合した個体が生き残った」っていうのが正しい理解。画一化は逆に脆弱性。
最近のSNSでは、他人のコンテンツを使った煽り投稿や、承認欲求を狙った浅いコンテンツが目立つ。コンテンツサービスとかでも稼げる方法として普通にアダルトな要素のコンテンツ販売とかが紹介されたりする。インプレッション＝ビジネスチャンスっていう構造上仕方ない面もあるけど、社会のノイズを増やすだけの行為は価値を生まない。カルチャー界隈でも、知的な議論や批評が重視されてきたけど、AIがその領域でも力を発揮するようになった今、「Deploy or Die」の精神で、考えたことは実際に製品サービスにしていく社会に説いていってくれ。そうじゃなくて、いい感じのフォロワーつけて、その中でワイワイやるなのなら、大きいことは言わんでくれ。
あと、これは完全に個人の主観なので悪気はないんだが、SNSのインプレッションを取るための傾向として、演者や自分の顔をデカデカと載せるのが増えてる。正直人間の顔を見たくない。何のコンテンツなのかわかるようにしてくれ。その中でお前の顔が写ってしまうのは仕方ないけど、毎回顔を載せたり煽ったりして、「これなら視聴者がクリックするんだろう」みたいなのを感じ取ったやつは、正直その時点で萎える。
「コンフォートゾーンを出ろ」みたいな話も正直嫌いだな。これも生存者バイアスがかかってる気がする。そういうことを言ってる人も、5年後10年後には完全にそのビジネス失敗することだってあるし、その一瞬の状態で生きてる人が言ってる場合も多いんじゃないかと思う。どちらかと言うと、コンフォートゾーンを出るとか競争だとか努力至上主義みたいなことよりも、単純に一人ひとりの好奇心を大事にしようって方がよほど説得力がある。周りを寄せつけないくらいの好奇心で掘れ。変に資本主義とか短期的な利益に流されないから、世の中的に面白いものが生まれてくると思うんだよね。考えてみろよ、賛否両論はあるけど、ジークアクスはコンフォートゾーンを出ろ論や資本主義を意識して出てくると思う？あんなの子供心と好奇心の産物だろ。まあ逆かもしれんがなｗ
一人ひとりができることが増えて、アクセスできる情報や知能レベルが爆発的に向上した今こそ、既存の構造を打破する新しい取り組みが生まれることを期待してる。変化の激しい時代だからこそ、本質的な価値とは何かを見極める目が大切だと感じてる。みんな他の人がやってることじゃなくて、おもろいことしようぜ。
2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。
この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。
本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。
LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。
コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。
この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。
風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。
TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。
テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。
この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。
TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。
Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。
しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。
この「WhatからHowへの変換」は、様々な領域で見られる。
これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。
現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。
フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。
前章で述べたように、ReactやTerraformといったフレームワークは、その恩恵と引き換えに、私たちに特定の「制約」を課してきた。Reactを使うならコンポーネントベースで思考し、状態管理の作法に従う必要がある。Terraformを使うなら、そのエコシステムとHCLの流儀を受け入れなければならない。これらの制約は、WhatからHowへの変換を自動化するための「レール」であり、私たちはそのレールの上を走ることで効率を得てきた。
しかし、LLMはこの前提を覆す。LLMは、特定のフレームワークや言語の知識を事前に学習しているが、その利用において絶対的な制約を課すわけではない。私たちは、より自由な形式で「What」を伝えることができる。
例えば、こうだ。
ユーザー認証機能付きのシンプルなブログアプリを作ってほしい。フロントエンドはReactとTypeScript、UIコンポーネントはMUIを使う。バックエンドはNode.jsとExpressで、データベースはPostgreSQL。ユーザーはGoogleアカウントでログインでき、新しい記事を作成、編集、削除できる。記事にはマークダウン記法が使えて、画像もアップロードできるようにしてほしい。
この要求（What）は、特定のフレームワークの流儀に則ったものではない。複数の技術スタックを横断し、機能要求を自然言語で並べただけのものである。しかし、現在のLLM、特にGPT-4oやそれに類するモデルは、このレベルの要求から、ディレクトリ構造、設定ファイル、APIエンドポイント、フロントエンドコンポーネントに至るまで、驚くほど具体的なコード（How）を生成することができる。
これは、フレームワークが担ってきた「WhatからHowへの変換」が、特定のレールから解き放たれ、より広範で柔軟な領域へと拡張されたことを意味する。これまで自動化が難しかった、あるいは特定のフレームワークが存在しなかったニッチな領域や、複数の技術を組み合わせる複雑なシステム構築においても、AIによる宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。
LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。
質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。
これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。
やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。
「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。
答えは、明確にNoである。
ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。
簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザーIDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。
これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。
LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。
これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。
ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。
私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single PageApplication）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「Permalink |記事への反応(0) | 17:09
2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。
この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。
本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。
LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。
コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。
この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。
風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。
TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。
テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。
この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。
TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。
Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。
しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。
この「WhatからHowへの変換」は、様々な領域で見られる。
これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。
現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。
フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。
前章で述べたように、ReactやTerraformといったフレームワークは、その恩恵と引き換えに、私たちに特定の「制約」を課してきた。Reactを使うならコンポーネントベースで思考し、状態管理の作法に従う必要がある。Terraformを使うなら、そのエコシステムとHCLの流儀を受け入れなければならない。これらの制約は、WhatからHowへの変換を自動化するための「レール」であり、私たちはそのレールの上を走ることで効率を得てきた。
しかし、LLMはこの前提を覆す。LLMは、特定のフレームワークや言語の知識を事前に学習しているが、その利用において絶対的な制約を課すわけではない。私たちは、より自由な形式で「What」を伝えることができる。
例えば、こうだ。
ユーザー認証機能付きのシンプルなブログアプリを作ってほしい。フロントエンドはReactとTypeScript、UIコンポーネントはMUIを使う。バックエンドはNode.jsとExpressで、データベースはPostgreSQL。ユーザーはGoogleアカウントでログインでき、新しい記事を作成、編集、削除できる。記事にはマークダウン記法が使えて、画像もアップロードできるようにしてほしい。
この要求（What）は、特定のフレームワークの流儀に則ったものではない。複数の技術スタックを横断し、機能要求を自然言語で並べただけのものである。しかし、現在のLLM、特にGPT-4oやそれに類するモデルは、このレベルの要求から、ディレクトリ構造、設定ファイル、APIエンドポイント、フロントエンドコンポーネントに至るまで、驚くほど具体的なコード（How）を生成することができる。
これは、フレームワークが担ってきた「WhatからHowへの変換」が、特定のレールから解き放たれ、より広範で柔軟な領域へと拡張されたことを意味する。これまで自動化が難しかった、あるいは特定のフレームワークが存在しなかったニッチな領域や、複数の技術を組み合わせる複雑なシステム構築においても、AIによる宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。
LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。
質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。
これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。
やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。
「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。
答えは、明確にNoである。
ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。
簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザーIDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。
これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。
LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。
これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。
ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。
私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single PageApplication）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「Permalink |記事への反応(0) | 17:09
根幹は、人間を自己完結した情報処理システムと捉える点にある。
システムは、外部からの入力を受け、内部で処理し、外部へ出力する一連のプロセスを絶えず行っている。
「静寂」とは、単なる音の不在ではなく、システムの目的遂行を阻害するあらゆる「雑音」が極小化された状態を指す。
ノイズは二つに大別される。
「静寂を手に入れる」という行為は、内外のノイズを能動的に制御し、システムが処理すべきS/N比を意図的に最大化するプロセスに他ならない。
この最大化がもたらすメリットは、単一の事象に留まらず、システムの全機能の最適化として現れる。
この技法が示すのは、自己というシステムの情報エントロピーを最小限に抑え、その内在的ポテンシャルを最大限に解放するための方法論である。
意識的に静かな場所に身を置き、静寂そのものを体験する時間を作る。
通知の完全オフ:スマートフォンの緊急性のないアプリ（SNS、ニュース、ゲーム等）のプッシュ通知を全て無効化する。
情報断食: 就寝前1時間や食事中、週末の半日など、一切デジタルデバイスに触れない「オフラインの時間」をスケジュールに組み込む。アプリの数を最小限に絞り、フォルダにまとめる。特に中毒性の高いアプリは削除する。
プル型への転換:SNSのタイムラインを漫然とスクロールする（プッシュ型）のではなく、「この情報を調べる」という目的を持って能動的に情報を取りに行く（プル型）習慣をつける。
時間と量を決める:ニュースやメール、チャットアプリをチェックする時間を決め、それ以外の時間は開かない。
呼吸瞑想: 1日5分でも良いので、静かな場所に座り、ただ自分の呼吸（鼻を通る空気、お腹の膨らみとへこみ）に意識を集中させる。思考が逸れたら、それに気づいて優しく呼吸に意識を戻す。
観察瞑想: 湧き上がってくる思考や感情を「〜と考えているな」「〜と感じているな」と心の中で実況中継（ラベリング）する。それらを評価・判断せず、ただ流れる雲のように観察する練習。
ブレインダンプ: 朝起きた時や夜寝る前に、頭の中にある心配事、タスク、アイデアなどを、構成を考えずに紙に書き出す。思考を外部化することで、頭の中が整理され、客観的に見つめ直せる。
シングルタスクの徹底:複数の作業を同時に行うマルチタスクをやめ、一つの作業に集中する。タイマーを25分にセットして一つのタスクを行い、5分休憩するポモドーロ・テクニックは有効。
意識的な呼吸:ストレスや不安を感じた時に、4秒かけて鼻から吸い、6〜8秒かけて口からゆっくり吐き出す腹式呼吸を数回行う。副交感神経を優位にし、心身をリラックスさせる即効性がある。
自然との接続: 週に一度でも、公園を散歩したり、森林浴をしたりする時間を作る。自然環境は、人間のストレスレベルを効果的に下げ、注意力を回復させることが科学的に証明されている。
身体活動:ウォーキング、ヨガ、ストレッチなど、穏やかな運動を習慣にする。身体的な緊張をほぐすことは、精神的なノイズの低減に直結する。
日中の生産性は、夜の過ごし方、特に「就寝」というクリティカルなタスクをいかに成功させるかにかかっている。本記事では、つい夜更かししてしまうエンジニアのために、早寝を「技術」として体系化し、再現性のある形で実践するための具体的な手法を探求する。これは精神論ではない。あなたのQoLと生産性を向上させるための、実践的なスリープエンジニアリングだ。
我々エンジニアにとって、夜は不思議な魅力を持つ時間だ。日中の喧騒から解放され、思考は冴えわたり、ゾーンに入りやすい。しかし、その魅力的な時間は、往々にして「早寝」という、人間の生存に不可欠な基本プロセスを犠牲にすることで成り立っている。
「リファクタリングが楽しくなってきた」
これらの探求心はエンジニアの美徳であるが、同時に我々を「睡眠負債」という深刻な技術的負債へと導く。本稿は、この負債を返済し、持続可能な開発（と生活）を実現するための「早寝」という技術に焦点を当てる。
早寝を実装する前に、まずは現状のアーキテクチャに潜むアンチパターンを特定しよう。
就寝前のスマートフォンは、まさに同期的なブロッキングI/Oだ。SNSの無限スクロール、動画プラットフォームの自動再生、チャットアプリの通知。これらは我々の意識というシングルスレッドを完全に占有し、本来実行されるべきsleep()プロセスへの遷移を妨げる。
深夜まで続くコーディングや問題解決は、脳を極度の興奮状態にする。ベッドに入っても、アドレナリンやコルチゾールといったホルモンがCacheに残り続け、CPUがクールダウンしない。shutdown -hnowを叩いても、プロセスが終了しないのだ。
「夜更かしの供」として注入されるカフェインやアルコールは、一見するとパフォーマンスを向上させるように見える。しかし、これらは睡眠の質という重要なmetricsを著しく劣化させる、誤った依存関係だ。特にアルコールは、入眠を助けるように見えて、実はレム睡眠を阻害し、睡眠のアーキテクチャ全体を不安定にする。
不規則な就寝・起床時間は、体内時計という最も重要なCronジョブを破壊する。毎日異なる時間に実行されるジョブが安定した結果をもたらさないのと同様に、不規則な睡眠スケジュールは、日中のパフォーマンスを予測不可能なものにする。
では、どうすればこれらのアンチパターンを排除し、安定した早寝pipelineを構築できるのか。ここではSleepas Codeの概念に基づき、具体的なプラクティスを紹介する。
毎晩、同じ手順で就寝プロセスを実行することで、入眠を自動化する。
-PC/スマホのシャットダウン: 最も重要なステップ。物理的に電源を落とすか、手の届かない場所（別のコンテナ）にdeployする。
- 入浴: 38〜40℃のぬるめのお湯に15分ほど浸かる。これにより深部体温が一時的に上昇し、その後の下降とともに入眠が促される。これはHot-swapならぬHot-bathによるクールダウンだ。
静的コンテンツの消費: 激しい思考を伴わない、静的な情報（紙の読書など）に切り替える。電子書籍ではなく、紙媒体が望ましい。
ストレッチ: 軽いストレッチで、日中のcommitで固まった体をreleaseする。
すべての準備が整ったら、ベッドという本番環境にデプロイする。余計な思考はgitclean -fdで強制削除し、呼吸に集中する。
例：「夕食後のコーヒーが原因だった」→「カフェインの摂取は15時までというSLAを設ける」
早寝は、単に体を休める行為ではない。日中の高いパフォーマンス、明晰な思考、そして創造性を維持するための、最も効果的で再現性の高い「技術」だ。
我々はインフラをコードで管理し、CI/CDでデプロイを自動化するように、自身の睡眠もまた、技術と工夫によってコントロールできる。今夜、あなたのwhile(true)なループをbreakし、持続可能なパフォーマンスを手に入れるための第一歩を踏み出してほしい。
Happy sleeping!
日中の生産性は、夜の過ごし方、特に「就寝」というクリティカルなタスクをいかに成功させるかにかかっている。本記事では、つい夜更かししてしまうエンジニアのために、早寝を「技術」として体系化し、再現性のある形で実践するための具体的な手法を探求する。これは精神論ではない。あなたのQoLと生産性を向上させるための、実践的なスリープエンジニアリングだ。
我々エンジニアにとって、夜は不思議な魅力を持つ時間だ。日中の喧騒から解放され、思考は冴えわたり、ゾーンに入りやすい。しかし、その魅力的な時間は、往々にして「早寝」という、人間の生存に不可欠な基本プロセスを犠牲にすることで成り立っている。
「リファクタリングが楽しくなってきた」
これらの探求心はエンジニアの美徳であるが、同時に我々を「睡眠負債」という深刻な技術的負債へと導く。本稿は、この負債を返済し、持続可能な開発（と生活）を実現するための「早寝」という技術に焦点を当てる。
早寝を実装する前に、まずは現状のアーキテクチャに潜むアンチパターンを特定しよう。
就寝前のスマートフォンは、まさに同期的なブロッキングI/Oだ。SNSの無限スクロール、動画プラットフォームの自動再生、チャットアプリの通知。これらは我々の意識というシングルスレッドを完全に占有し、本来実行されるべきsleep()プロセスへの遷移を妨げる。
深夜まで続くコーディングや問題解決は、脳を極度の興奮状態にする。ベッドに入っても、アドレナリンやコルチゾールといったホルモンがCacheに残り続け、CPUがクールダウンしない。shutdown -hnowを叩いても、プロセスが終了しないのだ。
「夜更かしの供」として注入されるカフェインやアルコールは、一見するとパフォーマンスを向上させるように見える。しかし、これらは睡眠の質という重要なmetricsを著しく劣化させる、誤った依存関係だ。特にアルコールは、入眠を助けるように見えて、実はレム睡眠を阻害し、睡眠のアーキテクチャ全体を不安定にする。
不規則な就寝・起床時間は、体内時計という最も重要なCronジョブを破壊する。毎日異なる時間に実行されるジョブが安定した結果をもたらさないのと同様に、不規則な睡眠スケジュールは、日中のパフォーマンスを予測不可能なものにする。
では、どうすればこれらのアンチパターンを排除し、安定した早寝pipelineを構築できるのか。ここではSleepas Codeの概念に基づき、具体的なプラクティスを紹介する。
毎晩、同じ手順で就寝プロセスを実行することで、入眠を自動化する。
-PC/スマホのシャットダウン: 最も重要なステップ。物理的に電源を落とすか、手の届かない場所（別のコンテナ）にdeployする。
- 入浴: 38〜40℃のぬるめのお湯に15分ほど浸かる。これにより深部体温が一時的に上昇し、その後の下降とともに入眠が促される。これはHot-swapならぬHot-bathによるクールダウンだ。
静的コンテンツの消費: 激しい思考を伴わない、静的な情報（紙の読書など）に切り替える。電子書籍ではなく、紙媒体が望ましい。
ストレッチ: 軽いストレッチで、日中のcommitで固まった体をreleaseする。
すべての準備が整ったら、ベッドという本番環境にデプロイする。余計な思考はgitclean -fdで強制削除し、呼吸に集中する。
例：「夕食後のコーヒーが原因だった」→「カフェインの摂取は15時までというSLAを設ける」
早寝は、単に体を休める行為ではない。日中の高いパフォーマンス、明晰な思考、そして創造性を維持するための、最も効果的で再現性の高い「技術」だ。
我々はインフラをコードで管理し、CI/CDでデプロイを自動化するように、自身の睡眠もまた、技術と工夫によってコントロールできる。今夜、あなたのwhile(true)なループをbreakし、持続可能なパフォーマンスを手に入れるための第一歩を踏み出してほしい。
Happy sleeping!
＊
だいわ文庫
＊
4.2/5平均レーティング: 5つ星のうち4.2つ星
前代未聞! 気鋭のコンサルが内幕を暴露した全米騒然の問題作! デロイト・ハスキンズ＆セルズ、ジェミニ・コンサルティングと、大手コンサルティングファームを渡り歩いてきた実力派コンサルタントが、自らとコンサル業界が犯してきた恐るべき過ちの数々を大暴露。「戦略計画」「最適化プロセス」「業績管理システム」……こうして企業は崩壊する。望ましいコンサルティング業務のあり方、クライアントとコンサルタントの正しい付き合い方を提唱する。
＊
【目次より抜粋】
はじめに御社をつぶしたのは私です
「数人のコンサル」が歪んだ流れをつくった
「確実にまちがっている」理論の数々
ほか
お得意の「人員削減」を自社で行うはめになる
ほか
ほか
正しく動くと評価されない
ほか
公正に見える「不公正」なシステム
ほか
ほか
一度の失敗が「致命的」になるシステム
ほか
■第七章 「リーダーシップ開発」で食べている人たち
ほか
コンサルタントの「使い方」
ほか
おわりに
＊
お客様はこの本について、以下のような評価をしています:ストーリーが爽快で、勉強になる良書だと感じています。コンサルの現実を追求した爽快なストーリーで、意外性があって面白かったと好評です。内容については論理的で、本質的な答となっている点も好まれています。また、著者の性格や人となりが表れているという指摘もあります。コミュニケーションについても、ツールは手段であって目的ではないことを再認識させる本だと評価されています。
システムエンジニア。社内システムの内製や開発会社と要件定義やスケジュール管理したりするいわゆる社内SE
昨今のAIの進化は日進月歩で寝て起きたら昨日学んだことが無駄になることも多い
職場もAI導入しているがセキュリティや内部情報の管理の為に巷で話題の技術にすぐ触れられないがそれなりに活用はできている
そんな中後輩がとにかくAI任せになるのだがとにかく雑でぱっと見でエラー分かるレベルだ。業務的にフルスタックな感じなので色んな分野を面倒見るがどの分野もAIに吐き出させその結果軽く動かして持ってくる。
別にAI任せは良いし今後はスタンダードだと思っているが、命令する側が知識無きゃAIは平気で嘘つくしゴミ回答でトークン無駄遣いする
そういう意味でドメイン知識や基本情報レベルのシステム知識はあった方がいいよと言ったが
と矢継ぎ早に言われてううんとなった
正直AIって自分で出来る人がすごく楽できて、いくらバイブコーディング言って初心者が二人三脚で作っても出来るアプリやサービスはその辺の技術書かUdemy課題レベル
そこから興味持って壁打ちでどんどん吸収するのは極々一部で大半は楽を覚えてシスアド以下で仕事した気になっちゃう
と氷河期世代のシステムエンジニアが心配しても流れは変わらないし今後どうなるんだろう。フルスタックで上流経験あっても若さ優先になるのかな〜辛いな
ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30
| ブクマ数 | タイトル | ドメイン |
|---|---|---|
| 1166 | デジタルアドレス｜日本郵便株式会社 | lp.da.pf.japanpost.jp |
| 1159 | 教皇選挙を終えて -司教の日記 | bishopkikuchi.cocolog-nifty.com |
| 862 | 花王 ｜日本の住環境における菌の実態調査 | www.kao.com |
| 710 | チームラボよ、どこへ行く？ | matsuuratomoya.com |
| 639 | 【悲報】ガンダムジークアクス、鶴巻和哉監督(59)が乃木坂46にんほる為の作品だと判明して炎上wwwwww | www.anige-sokuhouvip.com |
| 586 | ソフトウェアエンジニアがHondaに転職して感じたこと4選 -Honda TechBlog | honda-techblog.hatenablog.com |
| 570 | コラム「今の生成AI市場って焼き畑農業っぽくない？（2025年5月時点の所感）」｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典 | wa3.i-3-i.info |
| 539 | BIZUDPゴシックと99.99%同じだけど、数字が等幅の「帳票UDPゴシック」フォント公開 –プログラミング生放送 | pronama.jp |
| 526 | 川口市のクルド人 -河野太郎（コウノタロウ） ｜選挙ドットコム | go2senkyo.com |
| 512 | EXPO2025万博マニアックマップbyOpenStreetMap | k-sakanoshita.github.io |
| 498 | ボタンを「押下（おうか）する」という言い方はかなり昔から存在していた（文献引用つき） - StatsBeginner: 初学者の統計学習ノート | blog.statsbeginner.net |
| 464 | 郵便番号・デジタルアドレスAPI ｜郵便番号・デジタルアドレス for Biz ｜日本郵便株式会社 | guide-biz.da.pf.japanpost.jp |
| 456 | macOSSequoia (15.4 以降) で cal やdate を打つと出力がおかしい -id:onk のはてなブログ | onk.hatenablog.jp |
| 454 | 参政党 -sanseito- ｜新日本憲法(構想案) | sanseito.jp |
| 443 | 全ドット絵データベース | horicun.moo.jp |
| 439 | Obsidianおすすめプラグイン 〜日常記録、コードスニペット、ブログの下書きに〜 - neccoNote ｜ necco inc. | necco.inc |
| 419 | 『ソフトウェアエンジニアがHondaに転職して感じたこと4選』の記事削除について -Honda TechBlog | honda-techblog.hatenablog.com |
| 412 | ある日本人少年の物語中国が用いる手法 —情報操作とナラティブ・ジャミング -グローバル・ガバナンス研究センター（Institute for Global Governance Research：GGR）-一橋大学 | ggr.hias.hit-u.ac.jp |
| 407 | ゆめみ、アクセンチュアによる買収に合意 ｜ ゆめみ | www.yumemi.co.jp |
| 398 | Just fucking useHTML | justfuckingusehtml.com |
| 395 | ニッポン放送初の英語・語学学習ポッドキャスト番組！『AnimeEnglishClub withSally Amaki』 | news.1242.com |
| 394 | AWSの安価でスケーラブルなウェブアプリ構成2025年度版 -maybedaily devnotes | tmokmss.hatenablog.com |
| 391 | 神名データベース –國學院大學古典文化学事業 | kojiki.kokugakuin.ac.jp |
| 390 | 自分のiPhoneがどの電波（バンド）とつながっているのかを簡単に調べる方法 ｜イチオシ ｜ ichioshi | ichioshi.smt.docomo.ne.jp |
| 369 | Claude 4プロンプトエンジニアリングのベストプラクティス - Anthropic | docs.anthropic.com |
| 368 | 情報収集の仕方を模索している - 下林明正のブログ | shimobayashi.hatenablog.com |
| 366 | GitMCP | gitmcp.io |
| 358 | ずぼら女子による無肥料・無農薬・ほぼほったらかしでも育った作物、育たなかった作物ランキング【春夏編】 | agri.mynavi.jp |
| 353 | Gemini -HAL9000型との対話 | gemini.google.com |
| 352 | 中央図書館窓口等委託事業者の交代に伴う業務の停滞について -大阪市立図書館 | www.oml.city.osaka.lg.jp |
このネット投稿は、データ分析ライブラリであるPandasとAIを組み合わせたデータ処理について、その効率の悪さを強く批判しています。投稿者は、特に以下の点に言及しています。
この投稿は、PandasとAIを用いてデータベースから取得したデータを扱う際に、データの正規化を無視して不必要に結合したり、非効率なデータ構造を選択したりすることへの強い反発と、処理効率を重視するべきだという主張をしています。データベースやプログラミングにおけるデータ処理のベストプラクティスを理解していない、あるいは無視している実装に対しての批判と解釈できます。
司法令状を持たない、ICE職員による、裁判所内での逮捕を妨害したとして、ウィスコンシン州のハンナ・デュガン判事が逮捕されたことや、就任100日を受けた閣議でのヨイショ合戦については、日本でもそれなりに話題になった。
一方4月28日に発出された大統領令について、日本語で紹介されている記事が見当たらないので、紹介する。
アメリカでもそこまで話題になっているわけではないが、これらを受けたウィスコンシン州のエヴァース知事の声明などはそれなりにニュースになった。
「皆さんが、連邦保安局に逮捕されることはない、ということを知っています（だから安心して職務に励んでくれ）」
という発言をしているが、要は閣僚に限らず、警察にも免責するし、軍の武器も提供するし、警察が暴力的にならないようになされてきた合意を取り除こうとしている。
実際、ボンディは、3月に、ICEに対して、令状なしで不法移民の捜索や逮捕をしていいという通知を出しており、多数の合法移民やアメリカ市民への誤爆事例も出ているように、「不当な捜索及び押収」からの自由を保障する修正第四条に真っ向から衝突しているが、一切気にするそぶりはない（主語はPeopleであって、CItizenではないので不法移民であっても同じ）。
トランプのやり口の特徴的なところとして、仮想敵の悪魔化を支持者に植え付けるところがある。
「狂った極左（Radical Left Lunatics) 」だのが典型だが、サンクチュアリ、というのもそういう印象を与えようとしているのがよくわかる。小泉の聖域なき、にセンスが似ているか。
要は、「無法地帯を許すな」という体で、地方自治に踏み込んでいる。
基本的に修正第十条により、連邦政府は、州政府や州公務員に命令することはできない。そこで、予算止めるぞ、という脅しをかけているわけだ。
さらにホーマン大統領顧問はウィスコンシン州が、ICE職員が州職員の職場で移民を摘発しようとしたときのガイドラインを作ったことについて、犯罪である、との示唆をしている。
デュガン判事の拘束・起訴と兵糧攻めの脅しで屈服させようとしているのは明らかだろう。
実際の知事の逮捕については、ガイドラインを根拠に逮捕するのはいくら何でも無理筋だろう、とは思うが、正気の失い方、憲法との齟齬など一切気にするそぶりのなさからは、3か月ほどたったのちに、州警察の支援と称して配備された軍が州政府を制圧するようなニュースが飛び込んでくるかもしれないね。万が一そんなことがおきたなら、軍や警察が命令に背くことを期待したいが、ICEの脳死活動を見てると期待はできないね。
4月18日：エヴァース知事が、急増する州職員からの問い合わせに対応する形で、ICEの移民摘発への対応ガイドラインを示す
4月18日：デュガン判事が、ICEによる被疑者拘束をめぐり「司法令状ではない行政令状では入室できない」として被疑者を教室外へ誘導。
4月25日：FBIがデュガン判事を逮捕・訴追（2件の連邦刑事罪で起訴）
5月1日：エヴァース知事のガイドラインについての質問を受けたホーマン大統領顧問が、以下のように発言
「何が起きるか楽しみにするといい。私が言いたいのは、われわれを支持しないのも、サンクチュアリ都市を支持するのも自由だが、違法外国人を意図的にかばったり、逃がしたりした場合は、重罪人であり、そのように扱うということだ。」
これを受けて、共和党の州議会議員がエヴァース知事が手錠をされているAI画像をポスト。
5月3日：エヴァース知事が、脅しには屈しない旨をyoutubeで異例のメッセージ
https://www.youtube.com/watch?v=BIjggk-9mO0
このガイダンスはコネチカット州や、移民支援団体も推奨している対応策とほぼ一致（PBS Wisonsinの記事参照）。
デュガン判事の対応もこのガイドラインに従っており、時系列的にどちらが先だったのかは今後の裁判で明らかになると思われる。
一部の州および地方の役人は、連邦移民法の執行に違反し、妨害し、逆らうために彼らの権限を行使し続けている。これは、連邦法の優越性と、米国の領土主権を擁護する連邦政府の義務に対する無法な反乱である。また移民に関して連邦法は州に対し絶対的に優越しており、州はそれを妨げることは許されない。
施行から30日以内に司法長官と国土安全保障長官が連邦法執行を妨害する州・地方自治体をリスト化し公表、対象自治体に通知する。
指定自治体への連邦助成金・契約金の「停止または打ち切り」をDOGEが適法に実施する。
サンクチュアリ自治体への指定後、なお是正しない場合、司法長官と国土安全保障長官が訴訟や刑事捜査を含むあらゆる法的手段を講じる。
サンクチュアリ地域内で民間事業者が提供する連邦公的給付（医療・福祉等）について、受給資格の厳格確認を義務化するとともに必要に応じて給付を停止
州法で不法滞在者向けに学費優遇や刑事処遇の優遇を行う自治体に対し、連邦法（8 U.S.C. § 1623等）違反として是正、アメリカ市民の権利保護を最優先とする監視態勢を強化
地方リーダーが法執行機関を名指しで非難し、積極的な取り締まりを法的・政治的な足枷で妨げると、犯罪がはびこり、無実の市民や小規模事業者が被害を受ける。
司法長官は、法執行業務の遂行中に不当な負担や損害賠償を被った警察官に対し、法的支援および補償を提供する仕組みを整備する。
(a)司法長官および関係行政機関の長は、連邦資源を最大限に活用し、以下の施策を推進するものとする。
(i)犯罪抑止に向け、攻撃的に取り締まるための最新ベストプラクティスの提供
(b) 本令発出後60日以内に、司法長官は、州・地方の法執行機関が当事者となっている連邦同意判決、裁判外合意、判決後命令をすべて点検し、法執行機能を不当に制約しているものについては修正・解除・終了を図る。
（同意判決とは、連邦政府と地方の警察の間でよく結ばれる、合意であって、違反すると州裁判所から罰則があるタイプの和解のこと。警察の活動の抑制や市民からの苦情の件数などに数値目標が定められ、警察が謙抑的にふるまうための措置になりがち。要はそういうのをとっぱらえ、と言っている。）
(a) 本令発出後90日以内に、司法長官および国防長官は、国土安全保障長官等と協議の上、余剰の軍事装備や国家安全保障資産を地方自治体へ提供し、州・地方警察の支援にあてる。
(b) 同じく90日以内に、国防長官は司法長官と連携し、軍事・安全保障資産、訓練、非致死性装備、人員を最も効果的に活用する方法を決定する。
司法長官は、犯罪被害を受けたアメリカ人の権利を守るため、必要な法的手段と捜査・起訴を優先的に行う。特に以下の行為を行った州・地方公務員を対象とする。
(a)公共の安全と治安維持に必要な法執行を故意に不法に妨害した場合
セルフのアナルデベロップメントプロジェクトにアサインされた当初、私は正直、ミッションのスコープがあまりにもアンビギュアスで、コンセンサス形成に時間がかかることを危惧しておりました。しかしながら、ワークショップ形式でのブレインストーミングを複数回実施し、アサンプションの洗い出しからペインポイントの可視化までをワンストップで対応することにより、当該プロジェクトのコアバリューが徐々にクリスタライズされてきました。
ファシリテーションの観点から言えば、イニシアチブを自ら取り、レバレッジの効いたリソース配分を意識することで、タスクフォース全体のシナジーを最大化できたと自負しております。また、KPIベースでのセルフモニタリングを徹底することで、アジャイルな改善サイクルを回しながら、想定以上のインパクトをクイックウィンとしてデリバーできました。
一方で、アナル領域という極めてセンシティブなフィールドにおいては、ユーザーエクスペリエンス（UX）を損なわずにデベロップメントを加速させるには、サステナブルかつインクルーシブなアプローチが不可欠であると再認識いたしました。従来のウォーターフォールモデルでは対応しきれないフェーズに突入したため、ここでは敢えてデザインシンキングを導入し、ヒューマンセンタードなパースペクティブでのアプローチにピボットする判断をいたしました。
最終的には、全ステークホルダーがアラインし、全社的なコンセンサスのもとで、当該プロジェクトをクローズすることができました。今後はナレッジを水平展開し、ベストプラクティスとしてイントラにドキュメント化する予定です。
ベン・バーナンキはFRB議長指名を受けての上院銀行委員会の公聴会においてグリーンスパン路線の継承を約束した。バーナンキは90年代からグリーンスパン後の金融政策のあり方のひとつとして、インフレターゲット政策を採用すべきだとする論陣を張っていた。この上院での証言では、まさに物価安定と経済成長の安定、そして市場とのコミュニケーションを円滑に行うためにインフレターゲット導入が必要であると、バーナンキは力強く述べた。このバーナンキ証言に対して、委員会のメンバーからインフレターゲットを採用することで物価安定が優先されてしまい雇用の確保が保たれないのではないか、という質問がだされた。それに対してバーナンキはインフレターゲットは物価と雇用の安定に共に貢献することができると言い切っている。
インフレターゲットとは、改めて定義すると、インフレ率の一定の範囲（例えば２～４％）におさえることを中央銀行が公表し、その達成のために必要な金融政策を行うことである。ただしバーナンキ自身がかっていったように何がなんでもインフレ率の達成にこだわるような、「インフレ狂のいかれぽんち」に陥ることはない。
バーナンキ自身は、現実の経済は非常に複雑であり、また不確実性を伴うものであるので、しばしばいわれる金融政策とその政策担当者を「自動車と運転手」の関係に喩えるのは誤りであると述べている（講演「金融政策の論理」2004年１２月2日）。なぜなら運転手は自分の走行中におこることがらをかなりの程度予測して運転しているが、金融政策の担当者には四半期先の予想でさえも困難なことが多い。確かに金融政策を通じて中央銀行は経済主体の予想に働きかけることができるが、それがどのように現実の経済に反作用するかを見極めることは実に難しい。しかしそれだからこそこの複雑で不確実な経済において経済主体の予想に働きかける政策の方が、それを考慮しない政策よりも重要になる。なぜなら主体がどのように政策に反応するかの理解を欠いた政策実行は予期しない失敗を引きおこすからである。
そして経済主体の予想形成とその経済への反作用をしっかりと政策当局が見極めるためには、予想をベースにした政策の実行とともに市場参加者と中央銀行とのコミュニケーションがきわめて重要になる、とバーナンキは述べている。そして中央銀行は市場に対してその政策の目的や予測を伝えることで、市場からのリアクションに対して柔軟に対応するべきである、とも述べている。これらの政策に対する基本姿勢は、彼のインフレターゲット論の中にいかんなく反映されている。
従来の経済学では金融政策をめぐっては、「ルールか裁量か」という二元論でしばしば議論が行われている。金融政策が長期的には貨幣の中立性が成立していて、実体経済には影響を及ぼさずに、ただ単に名目変数（例えば物価水準）を動かすだけである、という点では新古典派経済学・マネタリスト、そして（ニュー）ケインジアンは一致している。しかし短期的に実体経済に影響を及ぼすことができるのか、いいかえると経済の深刻な変動に対して金融政策は有効な手段になるのかどうかで、新古典派とケインジアンには特に深い対立が残っている。
現時点で新古典派とマネタリスト、そしてケインジアンは非常に深く混じってしまっており、例えばバーナンキの初期の金融モデルは新古典派的な発想に立脚したRBCモデルを基本にしている。しかし、最近のバーナンキの政策スタンスは経済の変動（産出量ギャップの大きな変化）には積極的な金融政策中心の政策対応をすすめるものであり、その基本はまぎれもなくケインジアンである。そして財政政策よりも金融政策を中心に景気対策を行う点では昔風？の区分ではマネタリストでもあるだろう。
一般的に新古典派やマネタリストは中央銀行がマネタリーベースを四半期ごとにX%にコントロールする「ルール」に準拠して金融政策を行うことで、中央銀行が戦前の大恐慌時のように大きな経済変動の原因になることを未然に防ぐことができるとし、安定的な経済成長に資することができると考えている。そしてルールを事前に公表することで中央銀行の行動に対して市場が信頼をもつことができることも経済の不安定性を回避するとルール主義者は信じている。それに対して裁量を重視する旧来のケインジアンは産出量ギャップの拡大に対して機動的な政策対応を主張している。裁量主義者はルールのもたらす「信頼」と、大恐慌のような予期しない経済変動に迅速に対処する際の政策の「柔軟性」にはトレードオフの関係があると信じて疑っていない。もし柔軟性を認めれば、そのことがマネタリストの主張するようなマネタリーベースの成長率ルールへの信頼性を損ねるというわけである。
バーナンキのインフレターゲット論は、この「ルールか裁量か」でいえばまさに彼の経済学の総合的性格を反映するかのように、彼自身の言葉で「制約された裁量」というコンセプトに即したものである。バーナンキの「制約された裁量」としてのインフレターゲット論は、バーナンキらの論集『インフレターゲット：国際的経験からの教訓』やFRB理事としての講演「インフレ目標の展望」（2003年3月25日、ベン・バーナンキ『リフレと金融政策』（高橋洋一訳、日本経済新聞社）に収録）に表明されている。
バーナンキのインフレターゲット論の主要内容は、１）フレームワーク、２）コミュニケーション戦略 のふたつで構成されている。フレームワークとは、先ほどの制約された裁量と同じであり、金融政策をいかに行うかについての「ベスト・プラクティス」（最善の実践）であるという。
「制約下の裁量のもとで、中央銀行は、経済構造と政策効果について知識が不完全なことに注意を払いながら、短期的な混乱は無視してでも生産と雇用の安定のために自主的に最善を尽くせます（これが制約下の裁量の「裁量」部分です）。しかし決定的に重要な条件は、安定化政策を実施するにあたり、中央銀行がインフレーーそして、それゆえ国民のインフレ予想??をしっかりとコントロールするという強いコミットメントを維持する必要もあるということです（これが制約下の裁量の「制約下」部分です）」（邦訳39頁）。
そしてこのようなインフレターゲットは金融政策が通常、半年から1年半ほどの政策ラグを伴って効果があらわれるために、先行して経済主体の予想をリードしていくという性格を色濃くもった期待形成のフレームワークでもある。
例えば、今日のアメリカ経済の低インフレの好循環が成立している背景には、まさに低インフレ予想がキーであるといえる。その反対のケースが70年代の石油ショックのエピソードである。産油国の石油価格の戦略的値上げによってコストプッシュ型の激しいインフレが起きたというのが定説である。しかしバーナンキは実際には石油価格の高騰が各種財やサービスのコストを引き上げたことによってインフレが多少は悪化したのは事実であるが、むしろそれよりも深刻だったのは家計や企業がFRBの金融引き締めが不十分であることを予想し、それが高いインフレ予想を招き、そして賃金値上げや製品価格値上げに移行した、という見方を立てている。むしろFRBが石油ショックに直面する以前の金融緩和姿勢もそのような経済主体の高インフレ期待を促したともバーナンキは指摘している。
実は日本でも石油価格の高騰が70年代の「狂乱物価」を引き起こしたとする通説が根強い。しかし小宮隆太郎は「昭和47，48年のインフレーションの原因」の中で日本銀行の石油ショック前の行き過ぎた金融緩和政策とその後の引き締めの遅れがこの「狂乱物価」の犯人であり、日銀の政策の遅れが（小宮はバーナンキのように期待の経路は明示していないが）企業や労働組合などに製品価格上昇や賃上げに走らせた、と述べている。そして70年代末から80年にかけての第二次石油ショックの影響が軽微だったのは、日銀が過去を反省していち早く強い金融引き締めスタンスを採用したことにあり、それに応じて（これも期待の経路は小宮では不明確なのだが）労働組合や企業も賃上げなどのコストプッシュの要因をおさえるべく、労使協調路線を採用することでこの事態を乗り切った、と書いている（小宮隆太郎『現代日本経済』東大出版会）。
アメリカの方はボルカー元FRB議長の1979年における断固たる“タカ派”的レジーム転換で、徹底的に高インフレと闘ったことで、その後の低インフレの好循環の基礎ができた、とバーナンキはボルカーの業績を評価している。しかし、このボルカーのタカ派へのレジーム転換が社会的にきわめて重いコストを伴ったことを指摘することをバーナンキは忘れていない。
ボルカーの行った「ディスインフレ」（高いインフレ率を抑えて低インフレにすること）政策が、積極的な名目利子率と実質利子率の引き上げによって実行され、それが80年代に入ってインフレ率の劇的な低下を見る一方で、それと見返りに10％にせまる高い失業を生み出してしまった。バーナンキはこの70年代のインフレ予想形成の失敗がいかに社会的コスト（失業）を生み出したのか、このような失敗を今後しないためにも経済主体の予想形成が金融政策の欠かせない要素になると力説している。
第二の要素のコミュニケーション戦略であるが、これはすでに自動車と運転手の比喩の話で触れたように、中央銀行が国民や市場参加者に対して政策目標、フレームワーク、経済予測を事前に公表することで、中央銀行の政策に対する信頼を醸成し、さらに政策責任の明確化と政策の決定過程とその帰結の透明性をはかろうというものである。このことが自動車と運転手の比喩でも問題となった経済の不確実性について、少なくとも政策当事者の行動とそれを予測する民間主体の不確実性を大幅に減少することは疑いがないであろう。
ところでこの「ベスト・プラクティス」としてのインフレターゲットがアメリカに導入される見込みはどうであろうか。従来、インフレターゲット導入への反対の論拠として、連邦準備制度の目的規定（連邦準備法２A条）とのダブルスタンダードになるという点をあげて反論するのが一般的であった。
「連邦準備制度理事会及び連邦公開市場委員会は最大雇用、物価の安定及び緩やかな長期金利という目標を有効的に推進するために、生産を増加する経済の長期的潜在性と均衡する通貨及び信用総量の長期的成長を維持する」
と連邦準備法にある。これはかってのハンフリー・ホーキンズ法の趣旨を反映した条文であるが、議会にもこの雇用と物価の両方への重視が強いことはすでに述べた。このようなダブルスタンダード批判について、バーナンキはここでインフレターゲットの柔軟性を強調し、雇用と物価双方にどんなウェイトづけを行っても首尾一貫したインフレターゲットの援用が可能である、と断言している。バーナンキ議長の意思が強固なことが伺われる。
今後、アメリカでインフレターゲット導入の議論が高まることは当然に予想される。この議論が高まることによって日本においても同様の議論が高まることが予想されよう。実際に政府の一部では強力にインフレターゲット導入を視野にいれた日銀法改正論議まで行われようとしているようである。すでに私はこのバーナンキ経済学を通して、日本銀行がその政策の説明責任、透明性、そして経済主体の予想形成、ほぼすべてにおいて稚拙な決定の連続であり、また今日においても外的な要因が重なっただけで金融政策のレジーム転換なきまま景気回復がある現状も指摘した。簡単にいえば、丸山真男が過去に指摘した官僚的な「無責任主義」がまだ日本銀行とその利益団体ともいえる日銀シンパのエコノミストに根強い。この無責任主義を打破するためにもインフレターゲットの導入とそれによるリフレマインドの形成が日本社会にいま最も望まれているように思われる。
#ホテル滞在中の乾燥対策ベストプラクティス：部屋環境と個人ケアの二軸から考える
快適な睡眠を得るためには、室内の湿度と気温が重要です。一般的な基準は以下の通りです。
エアコンを使用すると湿度が大きく下がりやすいため、加湿対策が重要になります。
> 参考：[NISHIKAWA 眠りのレッスン](https://sleep-natura.jp/infomation/futon_humidity01.html?utm_source=chatgpt.com)
---
### 洗面器やコップにお湯を入れて置く
洗面器やコップに熱めのお湯を入れて室内に置くことで、蒸発による加湿効果が期待できます。効果は限定的なので他の方法と併用がおすすめ。
> 参考：[MYGREEN GROWERS](https://mygreengrowers.com/blog/throat-dryness/?utm_source=chatgpt.com)
### 濡れたタオルを干す
濡れたタオルを室内に干すことで湿度を約4％程度上げる効果があります。複数枚干すことで加湿効果アップ。
> 参考：[WAFFLEBLOG](https://waffle.or.jp/rijicho-blog/post-10894/?utm_source=chatgpt.com)
###バスタブにお湯をためる
バスタブに熱湯を張り、浴室のドアを開けておくと湯気で室内が加湿されます。ただし持続性は低め。
> 参考：[＆H](https://and-h.com/column20230121/?utm_source=chatgpt.com)
---
###マスクの着用
就寝時に保湿マスクを使用することで、口や喉の乾燥を防ぎます。エアコン使用時に特に効果的。
> 参考：[NAFIASコラム](https://www.nafias.jp/column/660/?utm_source=chatgpt.com)
### 口閉じテープ
口呼吸を防ぐために口閉じテープを使うと、喉の乾燥やいびきを防ぐことができます。
> 参考：[松沢医院SASサイト](https://www.matsuzawa-sas.com/archives/1384?utm_source=chatgpt.com)
唇の乾燥防止に就寝前のリップケアを。保湿成分入りのものを選びましょう。
---
---
## まとめ
エアコンを使いながらも湿度を保ち、快適な睡眠を確保するには「部屋」と「自分」の両方から対策するのがコツ。持ち運びやすく、手間の少ない方法を組み合わせて、乾燥知らずのホテルライフを楽しんでください。
ただ、内容のチェックがだるい。
あと、AIに実装させるにしても、LFUやLRUの内容自体は知らないとAIに命令することができないんで、人間のほうも勉強しないとダメだな。
俺：
コードを生成する際、どこを参照したのかこたえよ。参照元のライセンスによってはあなたが書いたコードの影響を受けることがある。
AI：
私が生成したコードは、特定の参照元や外部資料を基にしているわけではなく、あくまで私のトレーニングデータに基づく知識から生成されたものです。私の知識は、公開されているさまざまな技術的なリソース（例えば、プログラミングの書籍、オープンソースプロジェクト、技術的なドキュメントなど）を含む一般的なパターンとベストプラクティスに基づいていますが、特定のソースコードや個別のプロジェクトを直接参照しているわけではありません。
そのため、私が生成したコードに関しては、特定の参照元や著作権の影響を受けることはありません。生成されたコードは私自身の知識ベースとアルゴリズムに基づいています。
ただし、一般的に言えば、私が提供するコードは、オープンソースのライセンス（例えばMITやApache）に準じて利用されることが多いですが、元々特定のソースを参照していないため、外部のライセンスに基づく影響を受けることはありません。
もし、あなたが提供したコードやアイデアが特定の著作権で保護されているリソースを参照している場合、そのリソースのライセンスに従って使用する必要があることに注意してください。
俺：
AI：
私のトレーニングデータは、OpenAIが収集した大量のテキストデータに基づいていますが、具体的な出典やデータセットの詳細については公開されていません。トレーニングに使用されたデータは、書籍、ウェブサイト、学術論文、オープンソースプロジェクトなど、さまざまな公開されている資料から収集されています。しかし、個別の出典を特定することはできません。
重要な点として、私が提供する情報やコードは、一般的なプログラミングの知識やベストプラクティスに基づいて生成されており、特定の個別のリソースを直接引用することはありません。また、私の回答はトレーニングデータに基づくパターン認識に基づいていますが、特定の著作権で保護された資料から直接コピーすることはありません。
もし特定のソースに依存する内容について心配がある場合や、トレーニングデータに含まれるリソースの詳細が必要な場合は、OpenAIの公式なポリシーやドキュメントを参照することをお勧めします。
出典元をどうやって取ったのか吐き出させる方法はないんだろうか？
いじめは特定の条件下で必然的に発生する現象という前提で、学校でワークショップとかやればいいのにな、座学じゃなくて
ていうか令和にまだイジメとかあんの？ダサすぎん？という空気になればいいのに
1. 「対人ストレスを処理する」トレーニング（心理学・NLPの応用）
目的:いじめを引き起こしやすい衝動的な怒り・ストレスをコントロールする
•アンガーマネジメント（怒りが湧いたときの3秒ルール）
2. 「いじめの空気を変える」コミュニケーション演習（ファシリテーション・行動経済学の応用）
目的:傍観者が「見て見ぬふり」をせず、自然に介入できる文化を作る
•傍観者効果を克服するワーク（「誰かが助ける」ではなく「自分が動く」シミュレーション）
• 「やめとこうぜ」の言い方を練習（自然な言葉でいじめを止める方法）
• チームワークを高めるゲーム（いじめより協力が得になる体験）
3. 「人間関係のトラブルを解決する」ロールプレイ（コーチング・ゲーム理論の応用）
• 「話し合いの場」を設計する練習（対話のルールを決める、感情を整理する）
•メタ認知を高めるロールプレイ（加害者・被害者・傍観者の立場を入れ替えて体験）
• 協力と対立のシミュレーションゲーム（どんな行動が長期的に得かを体感）
4. 「多様性の違和感を乗り越える」ワークショップ（行動経済学・NLPの応用）
• 「違いが武器になる」グループワーク（異なる個性を組み合わせた課題解決）
⸻
なぜ効果があるのか？
1. 単なる倫理の「お勉強」ではなく、実践的なスキルとして身につく
2.社会人の研修と同様に、現実の人間関係に直結するスキルが学べる
3.体験を通じて学ぶことで、より深く理解できる（行動変容につながりやすい）
———
教育現場で実効性のある施策を導入するには、KPIを設定し、PDCA（Plan-Do-Check-Act）サイクルを回しながら、教師の負担を抑えつつ継続的に改善していくことが重要です。
⸻
施策の効果を測定するために、以下のようなKPIを設定します。
✅ 生徒のメンタル指標（ストレスや孤独感のアンケートスコア）
✅ 「いじめに対する空気」の変化（自由記述アンケートやインタビュー）
✅ 「助けを求めやすさ」の意識調査（支援を求めることに抵抗を感じるか）
⸻
1. Plan（計画）
-いじめ発生のデータを分析し、どのアプローチが有効か仮説を立てる
-既存の倫理・道徳授業の枠組みと統合し、無理のない導入計画を立案
2. Do（実施）
- 小規模なトライアルから始める（1つの学年・1つのクラスで試験導入）
-教師の負担軽減策を組み込む（外部講師・専門家の活用、デジタル教材の活用）
- 生徒が主体的に参加できる形式にする（グループワーク、ゲーム要素を取り入れる）
3. Check（評価）
-KPIデータを定期的にモニタリングし、いじめ件数や関係性の変化を測定
- 定期的に内容をブラッシュアップ（教育現場のニーズに合わせて更新）
⸻
✅ 外部リソースの活用 →NPO・専門家・外部講師がワークショップを担当
✅デジタルツールの導入 →アンケート集計やデータ分析を自動化
✅ 生徒が主体的に運営 →いじめ防止委員会やピアサポートを設置
⸻
⚡最初から完璧を目指さず、小規模な実験を繰り返す（リーンスタートアップ方式）
⸻
このように、PDCAを回しながら教師の負担を最小限に抑えつつ、短期間で成果を検証し、改善を重ねることで、持続可能かつ効果的な仕組みを作れると思います。
ものによるけど簡単なのならManifestかScriptをちょろっと書き換えるだけで済む
拡張機能管理画面からID調べてPC内検索かけるとWindowsなら大体「%localappdata%\{ブラウザ企業}\{ブラウザ名}\User Data\Default\Extensions\{拡張機能ID}」にあるから
{拡張機能ID}\{version}\の中のmanifest.jsonをAIに投げて
「よく使っている拡張機能が「この拡張機能は、Chrome拡張機能のベストプラクティスに沿わないため、まもなくサポートされなくなる可能性があります。」で削除されそう。添付のjsonはこの拡張機能のマニフェストです。何が問題？」
みたいなことを言えば、なんかいい感じにどうすればいいか教えてくれるはず
練習用ソフトぐらいはいくらでも転がっているが、指の位置が把握できるものが良い
サーバー運用する上ではGUIに頼れないことが多いため、noxで使えるエディタをマスターしろ
ここにきてようやくプログラミング言語だ
まず共通知識としてHTML,CSS,JavaScriptぐらいは知っておいたほうが良いだろう
あとはどんなプログラマーを目指すかに依るが、組み込み系ならC言語、Web系ならphpやpython、機械学習ならpythonやRを学べ
シェルスクリプトは便利だから、bashをマスターするのも望ましい
要は効率的に処理を書ける必要があるが、LeetCodeやAtCoderで基本的な問題集を解けるようになれ
例えばpythonプログラマーなら、numpy, scipy, scikit-learnなどのライブラリのドキュメントを読めるようになれ
あるいはElasticsearchを使わなければならなくなったときに、ドキュメントを読んで操作できるようになれ
ドキュメントを読む経験が増えれば、新しく何かをやるときにすぐに着手できるようになる
AWSを有料で勉強するのはキツイので、就職後に先輩から学ぶか、あるいは認定試験を本やオンライン講座で勉強するのでもいいだろう
バージョン管理システムは知っておくべき知識だ
いわば、ソースコードの巨大なUndo,Redoみたいなもんだ
パスワードをどう管理すればいいのか、ネットワークセキュリティの仕組み、など基本的なセキュリティは学んどいたほうが良い
クリーンコードに関する書籍はたくさんあるので、時間があるときに読んでおけ
自分が使っているプログラミング言語に関連するベストプラクティスを学べ
