あさき@元数学教員エンジニア

元数学教員からIT業界へ転身。現在はシステムエンジニアとしてPHP（CakePHP）を中心に開発しています💻 Xでは学びの備忘録として、PHPフレームワーク（CakePHP, Laravel）の学習メモなどを発信中。1児🧒の父。個人で使う家計簿アプリを開発してます。
開発や技術学習中の方、ぜひ繋がりましょう！

[あさき@元数学教員エンジニア @from0Developer]

【Docker超入門 Day 1/6】そもそもDockerって何？🚀

Web開発で「Docker必須！」ってよく聞くけど、結局何がそんなに凄いの？を整理しました！

一言でいうと… 「アプリと必要な環境を丸ごと『箱（コンテナ）』に詰め込んで、どこでも同じように動かすツール」です📦
じゃあ、これまでのやり方と何が違うの？🤔

① PCに直接インストール（昔ながら） ・PCにPHPやMySQLを直接入れる ・「自分のPCでは動いたのに、本番環境だと動かない…」という環境差異の地獄が発生😱

② 仮想化（VMwareやVirtualBox） ・PCの中に「もう1台の仮想PC（ゲストOS）」を丸ごと作る ・環境は分離できるけど、OSをまるまる動かすので動作が重く、起動に数分かかる💦
③ Docker（コンテナ型） ・OSを丸ごと作るのではなく、ホストOSの仕組み（カーネル）をみんなで共有！ ・アプリを動かす「部屋（コンテナ）」だけを隔離して作る
💡 Dockerが最強な理由 とにかく「軽量で起動が爆速（数秒）」！ PCの中にいくつも独立した部屋を作っても、PCが重くなりにくいのが最大のメリットです✨

①と②の「なにがダメなの？」をツリーで詳しく解説します👇
#Docker #PHP #エンジニアの日常 #個人開発 #プログラミング初心者

[あさき@元数学教員エンジニア @from0Developer]

「メールアドレスの重複チェック、validationDefault と buildRules のどっちに書けばいいんだっけ…？」
​CakePHPで開発していて曖昧になりがちだったこの2つの違いを整理しました。
​・patchEntity() 時に動く形式チェック
・save() 時に動くDB整合性チェック
​なぜ2段階に分かれているのか、無駄なSQLを防ぐ仕組みから解説しています👇
​【CakePHP 5】validationDefaultとbuildRulesは何が違う？メールアドレス重複チェックで見る正しい使い分け
https://t.co/4ROGxPWLAP
#Zenn #CakePHP #PHP

[あさき@元数学教員エンジニア @from0Developer]

PHPの脆弱性（php2shell）、私の主担当はまだリリース前の開発中システムだったので緊急対応の修羅場は免れましたが、先週きっちりパッチ当て作業を行いました💻

具体的には、コンテナ内のPHPを対策済みバージョンに更新しつつ、再ビルドしても維持されるように Dockerfile 側にもバージョン定義を反映する作業でした🛠️

こういう時、Docker環境だとバージョンの引き上げや検証がサクッとできるので、改めてコンテナのありがたみを実感しますね💪

#PHP #Docker #エンジニアの日常 #Web開発

[すたーまん@メガベンチャーAIエンジニア @fujitech_ai]

確かに5年目までに結構できることはある。5年あればミドルエンジニアにはなれるから、ミドルレベルのAIエンジニアを目指すなら、1年目から5年目でやることはこう整理できる。

・1年目：新卒でも中途でも、最初の1年はIT企業の本業で先輩のレビューを受けながら実装を任される。並行して資格を取り、システム開発の基礎は基本情報・応用情報、AIはG検定・E資格で押さえる。
・2年目：1つの機能を要件確認からリリースまで持つ。そのために評価設計とハーネス設計を覚え、ビジネスのKPIとAIの評価指標のずれを埋めて、制約はハーネス側に置く。
・3年目：リリースしたプロダクトを土台に、MLOps・LLMOpsを設計・構築して運用する。ベテランが何を良しとするかを評価の仕組みに書き起こす。
・4年目：顧客やエンドユーザーの課題理解と要件定義、UI/UXの判断まで広げる。PoCを関係者のレビューに出して、次に何を作るかを決める。
・5年目：課題の定義から運用までをリードして、後輩のレビューで判断の基準を次に渡す。

これは今すでに実務にいる人にも当てはまる。伸びの目安は年数より、任される範囲が実装、機能、プロダクトと広がっているかどうか。技術の勘所とAIの使い方を両方持つエンジニアほど、この階段を早く上れるようになる。

[あさき@元数学教員エンジニア @from0Developer]

おはようございます。
在宅のいいところって、昼休憩で布団でぐっすり寝られるところだと思います。
5:00とかに起きて自学したりしてから仕事すると、脳のスタミナ切れみたいな感じで頭働かなくなる感覚があって。
出勤してても仮眠とることあるんですが、やっぱり布団で寝ると起きたときのスッキリ度が違いますね！

午後からも頑張ります！

[あさき@元数学教員エンジニア @from0Developer]

@upmills_0106 ぜひ交流させてください！👍

[あさき@元数学教員エンジニア @from0Developer]

CakePHPで関連テーブルの条件を使って親を絞り込みたいときの備忘録。

💡 クエリメソッドの役割 ・contain()：子データを一緒に読み込むだけ（親は絞り込めない） ・matching()：条件に合う親を INNER JOIN で絞り込む ・notMatching()：条件に合う子を持たない親を抽出
ハマった体験談をもとに解説しました👇
【CakePHP 5】contain()内のwhereで親テーブルが絞り込めない？matching() / notMatching()の正しい使い分け https://t.co/OAfYmy1VDP
#Zenn #CakePHP #PHP

[あさき@元数学教員エンジニア @from0Developer]

@uufu_engineer 私もよく写経します。
ただ読んでいるだけだと眠くなってきちゃって。。笑

真面目な話、写経って一旦読んだことを頭の中で短期記憶で覚えて自分で出力するので理解しやすいはありますよね！

[あさき@元数学教員エンジニア @from0Developer]

@upmills_0106 フォローありがとうございます！
初歩的な内容にはなりますが、同じような状況の方に見ていただけると嬉しいです！

よろしくお願いいたします！

[あさき@元数学教員エンジニア @from0Developer]

@Nicotine1016 そのときはぜひよろしくお願いします！🙇

[あさき@元数学教員エンジニア @from0Developer]

@Nicotine1016 ありがとうございます😄
次回転職することあれば参考にします！

[あさき@元数学教員エンジニア @from0Developer]

細かい機能単位で都度AIに投げてるとこうなる印象。
そのコードの用途にもよるけど、いざ自分で説明したり責任取らなきゃならなくなったときにどうかって話だよな。

[Yosuke Torii / ジンジャー @jinjor]

バイブコーディング辛い。コードが汚くなってることだけは分かるのに、自分はそのコードを理解してないから綺麗にする方法が分からない。

[Workaholic | 情報商材屋回避コンサル(笑) @32768Sf]

？？？

[あさき@元数学教員エンジニア @from0Developer]

府落ちしました。
横文字の正確な意味まで知っておかないと正確な意志疎通はできませんね。

[けんすう @kensuu]

これら、日本語と英語でそれぞれ意味が結構違ってて、、

エビデンスは「第三者が確認できる証拠・データ・資料」くらいの感じで、根拠はもっと広く、論理や言ってる人の経験、直感まで含んでもよいし、

ローンチは「世の中に出して、提供を開始する」というイベント全体のことをさすので、プレスリリースやSNSへのシェアなども含むが、公開は単に「見られる状態にする」という、点だけを指す意味が強い。

リスケは本来「予定を組み直す」なので、日時変更だけでなく、スケジュール全体の再調整まで含みうるんですよね。

というので、カッコいいから英語で言ってるんじゃなくて、「その意味の日本語ジャストのものがない」から使うケースが多いなぁ、と思ってます。

[あさき@元数学教員エンジニア @from0Developer]

やっぱりAIが書いてくれる時代でも、それなりのアウトプット量は確保していかないとダメですね。

[やねうら王 @yaneuraou]

AIを使って馬鹿になる人について考えるとき、「AIに頼ると頭を使わなくなる」といった話は、あまり本質的ではない。電卓が普及して暗算をする機会が減ったとか、Google Mapsのせいで道を覚えなくなったとか、その程度の話なら、人類は文字を発明した時点ですでに相当馬鹿になっているはずである。

もっと興味深い問題がある。

1983年、心理学者・人間工学研究者のLisanne Bainbridgeは「Ironies of Automation（自動化の皮肉）」という有名な論文を書いた。そこで指摘された逆説は、40年以上たった現在の生成AIにも驚くほどよく当てはまる。

機械が人間より上手にできる仕事を次々に自動化していくと、最後に人間に残されるのは何か。それは、機械がうまく処理できなかった例外的で、複雑で、判断の難しい仕事である。ところが、日常的な仕事を機械に任せれば任せるほど、人間はその仕事を自分で行う機会を失い、技能も状況理解も衰える。つまり、自動化が進むほど、人間の出番は減るのに、人間が出番を求められたときの仕事だけは難しくなる。Bainbridgeが「皮肉」と呼んだのは、この構造である。

たとえば、毎日100本のプログラムを書かなければならない人がいて、そのうち99本をAIが完璧に書いてくれるようになったとする。これは一見すると素晴らしい。しかし人間に回ってくる1本は、「なぜか本番環境でだけデッドロックする」「仕様書そのものが矛盾している」「二つの設計思想のどちらを採用するか判断しなければならない」といった、AIが処理できなかった難問になる可能性が高い。

つまり、その人は99本の普通のプログラムを書くことで本来得られたはずの訓練を失った状態で、100本中もっとも難しい1本だけを解かなければならなくなる。

これはなかなか意地の悪い仕組みである。

1995年、EndsleyとKirisは、この問題を「out-of-the-loop performance problem」として実験的に調べている。人間がシステムを直接操作する立場から、自動化されたシステムを眺めるだけの立場に移ると、単に操作技能が落ちるだけではなく、「いま何が起きていて、この先どうなるのか」という状況認識まで低下する。そして自動化システムが故障して突然人間に操作を返したとき、対応が遅れる。研究では、能動的な情報処理から受動的な情報処理へ移ることが、この低下の重要な原因として示唆されている。

これはプログラミングに限らない。部下が作った契約書を毎日チェックしている人は、長年のうちに「この条項は妙だ」という感覚を身につける。しかし契約書をAIが作り、AIがチェックし、人間は最後に「承認」ボタンを押すだけになれば、その感覚を獲得するために必要だった何千回もの小さな判断が消える。そして本当にAIが見落とすような珍しい契約上の問題が起きたときだけ、人間に判断が戻ってくる。

AIによる能力低下の恐ろしさは、「簡単な仕事ができなくなること」ではない。簡単な仕事を大量に経験することでしか育たなかった、難しい仕事を処理する能力まで失われることにある。

さらに厄介な問題がある。自分の能力が落ちていることを、自分自身が認識できなくなる可能性である。

心理学には「metacognitive calibration」という考え方がある。簡単に言えば、「自分がどれくらい正しいか」という自己評価と、実際の正答率がどれくらい一致しているか、という問題である。知識が多少不足していても、自分が何を知らないかを正しく認識できる人は比較的安全である。危険なのは、能力そのものより、このキャリブレーションが壊れることである。

2026年に『Computers in Human Behavior』に掲載された研究には、実に象徴的なタイトルがついている。

「AI makes you smarter but none the wiser」

直訳すれば、「AIはあなたを賢くするが、自分がどれほど賢いのかは分からなくする」といった意味になる。この研究では、LLMを使うことでLSAT型の推論課題の成績そのものは向上した一方、人々が自分の成績をどれだけ正確に評価できるかというメタ認知には問題が生じた。特に興味深いのは、AIリテラシーが高いことや自信が強いことが、必ずしも自己評価の正確さにつながらなかったという点である。

考えてみれば当然である。

AIなしで10問中6問解ける人が、AIを使うと10問中9問解けるようになったとする。このとき本人が観察できるのは「私は9問解けた」という結果だけである。しかし、その9問のうち何問が自分の能力で、何問がAIの能力なのかは、結果からは分離できない。

ここで、自分自身の能力を測るためのフィードバック系が壊れる。

筋力なら、100kgのバーベルを持ち上げられなければ自分の筋力不足はすぐ分かる。しかし、AIと一緒に100kgを持ち上げている状態では、自分が何kgまで持てるのか分からない。そしてAIの補助があまりに自然になると、そもそも「これは二人分の力で持ち上げている」という感覚すら薄れてくる。

私は、AI時代に本当に危険なのはここだと思う。

人間は無知であることには比較的耐えられる。「これは知らない」と自覚していれば、調べることができるからである。しかし、知らないという自覚そのものを失えば、調べるという行為も発生しない。

もう一つ、この問題を理解するうえで面白い古典的な実験がある。「generation effect（生成効果）」と呼ばれる現象である。

SlameckaとGrafは1978年の実験で、答えをただ読んだ場合と、自分で答えを生成した場合を比較した。すると同じ情報であっても、自分で生成したもののほうが、その後の記憶成績が良かった。これはさまざまな条件で確認された。

この現象をAIに当てはめると、少し嫌なことが見えてくる。

たとえば会議で「この新規事業の問題点を三つ考えてください」と言われたとする。五分間考えて、「市場規模」「競合」「人材」という三つを自分でひねり出す。その後ChatGPTに聞いたら、「法規制」「顧客獲得コスト」「既存事業とのカニバリゼーション」まで出てきた。この使い方なら、自分の思考にAIによる追加が行われる。

ところが最初から「問題点を10個挙げて」とAIに尋ね、その中からもっともらしい三つを選ぶだけになれば、自分が問題を生成する工程そのものが消える。

成果物だけを見れば後者のほうが立派である。だが、脳の中で起きたことはまったく違う。

これこそ、AIについて議論するときに「生産性」という指標だけを見てはいけない理由である。ある人がAIを使って以前の三倍の文章を書き、二倍のコードを書き、五倍の資料を作れるようになったとしても、その数字から本人の能力が向上したとはまったく言えない。極端な場合には、成果物の品質が上がるのと同時に、本人が単独で判断する能力は下がり、しかも本人にはその低下が観測できない、ということすら起こり得る。

そして、ここまで考えると「AIを使って馬鹿になる人」の特徴も少し違って見えてくる。

AIに質問する人が馬鹿になるのではない。AIに文章を書かせる人でもない。コードを書かせる人でもない。

AIが担当した認知過程と、自分が担当した認知過程との境界が見えなくなった人が危ないのである。

自分が考えたのか、AIが考えたのか。自分が理解したのか、理解しやすい説明を読んだだけなのか。自分に判断能力があるのか、AIが常に正解を横に置いてくれているから判断できているように見えるだけなのか。

この区別を意識的に維持できる人にとって、AIは恐ろしく強力な知的増幅器になる。

維持できない人にとっては、もっと恐ろしいものになる。

なぜならAIは、その人の能力を奪うときですら、本人には「以前より賢くなった」という感覚を与えることができるからだ。

だから、AIなんか使うな。

ちなみにこの文章は全文ChatGPTが書いた。

[あさき@元数学教員エンジニア @from0Developer]

@lnkiai @gmi_cloud 私をAIモデルに例えると「GPT-5.6 Sol」でした！
万能型オールラウンダー

#あなたをAIモデルに例えると
https://t.co/Mjo5Gstue8

[あさき@元数学教員エンジニア @from0Developer]

@lnkiai おめでとうございます！
Github Sponsors初めて知ったんですが、有料課金と違って純粋な支援なの嬉しいですね！

[あさき@元数学教員エンジニア @from0Developer]

💡 学びとまとめ
​・CakePHPの命名規約は「1対1の単純な参照」のときは最強に便利✨
・同じテーブルへ複数刺すときは、規約に頼らずエイリアス（FromUsers）と className（Users）で明示的に指定するのが実務解！
​「自動生成（bake）で上手くいかない…」と焦ったときは、規約の上書きを疑ってみてください💪

[あさき@元数学教員エンジニア @from0Developer]

【CakePHP実践ノウハウ】同じマスターのIDを複数持たせたら bake に怒られた話😱

​例えば「送信用ユーザー」と「受信用ユーザー」のように、同じ users テーブルのIDを1つのテーブルに持たせたくて from_user_id や to_user_id のようにプレフィックスを付けたんですが…
​
エラーになりました💦

​bake コマンドが from_users という存在しない別テーブルを探しにいっちゃうのが原因です。
​こうしたら解決しました👇
​#CakePHP #PHP #エンジニアの日常 #Web開発 #プログラミング初心者

[あさき@元数学教員エンジニア @from0Developer]

💡 なぜ起きるのか？
​CakePHPはデフォルトで {プレフィックス}_{単数形}_id を「プレフィックス_複数形 という名前のテーブルへの外部キー」だと解釈してしまうためです。
​
​🛠️ 解決策：Tableクラスでリレーションを明示する
​bake が自動生成したアソシエーション設定を、手動で className と foreignKey を使って上書き定義します👇

// src/Model/Table/MessagesTable.php 内の initialize()

// 送信元ユーザー
$this->belongsTo('FromUsers', [
'className' => 'Users', // 👈 本物の参照先テーブル（モデル）を指定！
'foreignKey' => 'from_user_id', // 👈 カラム名を明示
]);

// 送信先ユーザー
$this->belongsTo('ToUsers', [
'className' => 'Users', // 👈 同じく Users を指定！
'foreignKey' => 'to_user_id',
]);