やはりバックエンドエンジニアとしてはモデリング・認証認可周りが一番の肝ということで（強強エンジニアの受け売り）。
まずは認証認可周りから勉強していこう。
認証認可を勉強する理由としては、現在参画している現場でDevOpsとして動いているので、そこで貢献できそう。というのも大きい。
→Github actionsで全て書くのではなく、Terraform？CloudFormation？を使い、言語ごとのテンプレ作成し、標準化を目指す？
claudeに下記記事を解説してもらった。 www.anthropic.com
世界のAI採用は史上最速で進むが、その恩恵は高所得地域とコーディングタスクに極端に偏っている。Anthropicの2025年9月経済インデックスレポート（第3版）は、Claude.aiの100万件の会話と企業API利用100万件を分析し、AI採用パターンが20世紀の技術普及と類似した地理的集中を示しながら、はるかに速いペースで進行していることを明らかにした。米国従業員の40%が職場でAIを使用し、わずか2年で電気やインターネットが5年以上かけて達成した採用率に到達した。
歴史的に見て、変革的技術の普及には数十年を要した。電気は都市電化後、農村世帯に届くまで30年以上かかり、1981年に登場した大衆向けパソコンが米国の過半数の家庭に普及するまで20年を要した。急速に普及したインターネットでさえ、AIがわずか2年で達成した採用率に到達するには約5年かかった。
AIの急速な普及には3つの要因がある。第一に、既存のデジタルインフラ上で展開可能なこと。第二に、タイピングや音声による直感的なインターフェース。第三に、フロンティアAIの急速な能力向上が採用を加速している。しかし、この急速な普及にもかかわらず、AI採用は小数のタスクと地理的地域に集中しており、これは20世紀の技術普及パターンと類似している。
2024年12月〜2025年1月（V1）から2025年8月（V3）の8ヶ月間で、Claude.aiの使用パターンは顕著に変化した。
コンピュータ・数学タスクは依然として全体の36%で最大シェアを維持しているが、知識集約型タスクの成長が著しい。教育タスクは9.3%から12.4%へ、科学タスクは6.3%から7.2%へ上昇した。対照的に、ビジネス・財務とマネジメントタスクはそれぞれ6%から3%、5%から3%へ半減した。
コーディング内部でも構造的変化が起きている。新規コード作成は4.1%から8.6%へ倍増以上となり、デバッグ・エラー修正は16.1%から13.3%へ減少した。この正味7.4ポイントのシフトは、モデルの信頼性向上により、ユーザーが問題修正より創造に時間を費やせるようになったことを示唆している。
最も注目すべき変化はDirective（指示型）会話の急増である。ユーザーがClaudeに完全なタスクを委任する会話は、27%から39%へ12ポイント上昇した。これは今回のレポートで初めて自動化モードが拡張モードを上回ったことを意味する。
レポートはAnthropic AI Usage Index（AUI）を導入し、各地域のClaude使用率を労働年齢人口で調整して比較した。AUI > 1は人口比で期待される以上の使用を、AUI < 1は以下を意味する。
国別では、イスラエルがAUI 7.0でトップに立ち、労働年齢人口の7倍のClaude使用率を示した。シンガポール（4.57）、オーストラリア（4.10）、ニュージーランド（4.05）、韓国（3.73）が続く。主要先進国では米国が3.62、カナダが2.91、英国が2.67、フランスが1.94、日本が1.86、ドイツが1.84となっている。
一方、新興国では採用が著しく低い。インドネシアは0.36、インドは0.27、ナイジェリアは0.20と、人口比で期待される使用率を大幅に下回っている。統計的には、GDP per capitaの1%増加がClaude使用率の0.7%増加と相関している。
米国内でも同様の不均衡が見られる。カリフォルニアが総使用量の25.3%を占めるが、人口調整後ではワシントンDC（AUI 3.82）とユタ州（3.78）がカリフォルニア（2.13）を上回る。各州の使用パターンは地域経済を反映し、カリフォルニアはIT・デジタルマーケティング、フロリダはビジネスアドバイス・フィットネス、DCは文書編集・キャリア支援に特化している。
興味深い発見として、タスク構成を調整しても、低AUI国は自動化（タスク委任）を好み、高AUI国は協調的・学習的なインタラクションを好む傾向がある。これは、文化的・経済的要因、あるいは各国の初期採用者が自動化志向である可能性を示唆している。
使用の多様性にも差異がある。インドではコーディングタスクが全使用の過半数を占めるのに対し、高AUI地域では教育、科学、ビジネスへの分散が見られる。国別の特徴的な使用として、米国は家計管理と就職活動、ブラジルは法務と翻訳、ベトナムは教育とソフトウェア、インドはソフトウェア開発に集中している。
レポートは初めて企業API利用の詳細を公開した。個人ユーザーのClaude.aiと異なり、企業は77%が自動化パターン（タスク委任）で利用し、拡張パターン（協調的改善・学習）は12%にとどまる。Claude.aiでは自動化と拡張がほぼ半々であるのと対照的である。
API利用はソフトウェア開発に集中し、上位15カテゴリがトラフィックの約半分を占める。Webアプリのデバッグ、技術問題解決が各約6%、マーケティング資料作成が4.7%、AIシステムの開発・評価自体が約5%を占める点も注目される。
タスク分布は極端に偏っており、下位80%のタスクが使用量の10.5%しか占めない（ジニ係数0.86）。これはClaude.ai（12.7%、ジニ係数0.84）よりさらに集中している。
企業がどのタスクにClaudeを使うかは、コストより能力と経済的価値で決まる。高コストタスクほど使用率が高いという正の相関があり、タスク特性を調整しても、コスト1%増加は使用率をわずか0.29%減少させるにとどまる。10%のコスト削減でも使用率は3%程度しか増えない計算である。
より重要な制約はコンテキスト（文脈情報）へのアクセスである。複雑なタスクには不釣り合いに長い入力が必要で、入力トークン1%増加に対し出力トークン増加は0.38%にとどまる。これは、暗黙知や分散した組織情報を必要とするタスクでは、モデル能力よりデータアクセスがボトルネックになることを示唆している。企業が高度なAI展開を実現するには、データインフラの近代化と組織的投資が不可欠である。
レポートは、現在のAI採用パターンが既存の経済的不平等を拡大するリスクを指摘している。19世紀後半から20世紀初頭の変革的技術（電化、内燃機関、屋内配管）は近代経済成長をもたらしたが、同時に世界的な生活水準の大きな乖離を伴った。
高所得地域と自動化適応セクターに生産性向上が集中すれば、近年見られた成長収斂が逆転し、グローバルな経済格差が拡大する可能性がある。政策立案者はAI採用の地域集中に注意を払い、デジタルデバイドの深化を防ぐ対策が必要である。
労働市場への影響は複雑である。自動化可能なタスクを担う労働者は置換リスクに直面する一方、組織的な暗黙知を持つ労働者はAIの補完者として需要が高まる可能性がある。経験豊富な労働者の生産性向上は賃金上昇につながる可能性がある一方、エントリーレベルの労働者は厳しい雇用環境に直面するかもしれない。
AI駆動の経済変革はまだ初期段階にある。レポートは、技術採用のパターンは固定されたものではなく、技術の成熟、補完的イノベーションの出現、社会の意思決定により変化すると強調している。現在の高度に集中した使用パターンが、より広範で生産性向上の恩恵を広く分配する方向へ進化するかは、政策立案者、ビジネスリーダー、市民社会の行動にかかっている。
Anthropicは独立した研究を促進するため、タスク別使用パターン、協調モード、地理データを含む包括的なデータセットをオープンソースで公開している。このデータが、AI経済影響に関する仮説検証と、経験的証拠に基づく政策対応の開発に貢献することが期待される。
いままで、雰囲気で書いてたpythonで気になるところをChatGPTに聞いてみつつ、勉強したので、そのまとめ。
self・__init__・__new__・super() の整理本記事は、Pythonのクラス設計を学ぶ中で重要となる以下の概念を、仕組み・理由ベースで整理したまとめです。
self とは何か、なぜ明示するのか__init__ の役割__new__ はいつ使うのかsuper() とは何か初学者が「なんとなく」ではなく「腹落ち」することを目的にしています。
self とは何か？self は そのメソッドを呼び出したインスタンス自身 を指します。
class Person: def say_hello(self): print("こんにちは")
p = Person() p.say_hello()
内部的には以下と同等です。
Person.say_hello(p)
この p が self に渡されています。
self を明示的に書くのか？Pythonでは、メソッドも本質的には関数です。
これは Python の哲学である
Explicit is better than implicit.
（暗黙より明示的なほうが良い）
を体現しています。
__init__ の役割__init__ は 生成されたインスタンスを初期化するためのメソッドです。
class Person: def __init__(self, name, age): self.name = name self.age = age
a = Person("太郎", 20) b = Person("花子", 25)
一般的なOOPでは：
コンストラクタ = インスタンス生成 + 初期化
これは概念的には正しい理解です。
ただし Python では役割が分かれています。
| 役割 | メソッド |
|---|---|
| インスタンス生成 | __new__ |
| インスタンス初期化 | __init__ |
そのため Python では、慣習的に __init__ をコンストラクタと呼ぶことが多い、という位置づけになります。
__new__ とは何か？__new__ は インスタンスを生成して返す責任を持つメソッドです。
class A: def __new__(cls): instance = super().__new__(cls) return instance
self ではなく cls__new__ を使う代表的なケースclass MyInt(int): def __new__(cls, value): return super().__new__(cls, value)
int, str, tuple は不変（immutable）__init__ では変更できないclass Singleton: _instance = None def __new__(cls): if cls._instance is None: cls._instance = super().__new__(cls) return cls._instance
class Shape: def __new__(cls, kind): if kind == "circle": return super().__new__(Circle) return super().__new__(cls)
super() とは何か？super() は
継承関係における MRO（メソッド解決順序）上の「次のクラス」
のメソッドを呼び出すための仕組みです。
super() の基本例class Animal: def __init__(self): print("Animal 初期化") class Dog(Animal): def __init__(self): super().__init__() print("Dog 初期化")
Dog()
Animal 初期化 Dog 初期化
super() を使うのか？Animal.__init__(self) のような直接呼び出しは、設計変更に弱くなります。
super()class A: pass class B(A): pass class C(B): pass C.mro()
[C, B, A, object]
super() は、この順序に沿って次のクラスへ処理を委譲します。
| 概念 | 要点 |
|---|---|
self |
インスタンス自身を明示的に受け取る |
__init__ |
インスタンスの初期化 |
__new__ |
インスタンス生成（特殊用途） |
super() |
継承チェーンを壊さず次へ委譲 |
self は「誰のデータか」を明示するために存在する__init__ は初期化専用__new__ は生成制御が必要なときだけ使うsuper() は継承設計の安全装置Pythonのオブジェクトモデルは、仕組みを知るほどコードが読みやすく・安全になる設計になっています。
めちゃくちゃ勉強になりそうな記事があったので、元記事をChatGPTに読み込ませて解説してもらった。
この記事（OpenAI公式: Scaling PostgreSQL）で語られている内容を、構成図（ASCII図）＋背景＋設計意図つきで詳しく解説します。
┌──────────────┐
│ Application │
│ (ChatGPT / │
│ API) │
└──────┬───────┘
│
PgBouncer
│
┌─────────┴─────────┐
│ │
Read Queries Write Queries
│ │
┌───────▼───────┐ ┌───────▼───────┐
│ Read Replica │ │ Primary │
│ (x 40〜50台) │ │ PostgreSQL │
└───────────────┘ └───────┬───────┘
│
Hot Standby
👉 「RDBはスケールしない」という通説を、読み込み特化設計で覆している
| 方法 | 課題 |
|---|---|
| シャーディング | トランザクション、JOIN、運用が地獄 |
| NoSQL全面移行 | 強整合性が失われる |
👉 「まずRDBを限界まで使い切る」という思想
Write Heavy Data
│
┌────────▼────────┐
│ Cosmos DB 等 │ ← 水平分割しやすい
└─────────────────┘
Critical Data
│
┌────────▼────────┐
│ PostgreSQL │ ← 整合性重視
└─────────────────┘
👉 「全部Postgresに入れない勇気」がスケールの鍵
SELECT ...
│
Load Balancer
│
┌───────────┼───────────┐
▼ ▼ ▼
Replica A Replica B Replica C
👉 UX的に「即時一致」が不要な領域を正確に切り分け
[Client x N]
│
┌────▼────┐
│PgBouncer│ ← 接続プール
└────┬────┘
│ 少数
┌────▼────┐
│Postgres │
└─────────┘
👉 スケールの8割はコネクション制御と言ってもいい
Bad: SELECT ... JOIN ... JOIN ...; Good: SELECT simple_key FROM table; → アプリで組み立て
👉 DBは「計算機」ではなく「事実の保管庫」
Cache Miss
│
┌───────▼───────┐
│ Request Lock │ ← 同時多発防止
└───────┬───────┘
│
PostgreSQL
👉 DBに"雪崩"が起きるのを防止
Primary (Fail)
X
│
┌─────▼─────┐
│ Hot Standby│ ← 即昇格
└───────────┘
👉 可用性 > 完璧な整合性（短時間）
PostgreSQLは「スケールしない」のではなく、 設計せずに使うとスケールしないだけ。
今年読んだ本は34冊（漫画は全巻で1冊カウント）
1. 狂人たちの世界一周
怖すぎる。紀行文や探検ものは好きだが、登山家と同じく、クレイジーすぎて怖い。
到達できる保証がなく、生きて返れる保証もない中で、旅に出ていく。まさに狂人。
年始にざっと読んでしまったが、余生に再度じっくり読んでみたい1冊。
https://amzn.asia/d/iePSMrs
2. カウンセリングとは何か 変化するということ
東畑さんの書籍は数冊読んでいるが、タイトル通り「カウンセリングとは？」という問いに対して網羅的に説明されており、非常に分かりやすい。
理論だけでなく、フィールドワークとして今まで様々な場所で活動してきた東畑さんの言葉だからこそ、分かりやすく納得感が高い内容になっていたと思う。
改めて、ユングや河合隼雄を勉強してみたいという気持ちに。
https://amzn.asia/d/6lujN2y
3. LLMのプロンプトエンジニアリング
LLMについて分かりやすく解説されている。前半部分はエンジニアでなくてもAIを利用している人は勉強になると思う。
たびたび、「LLMは次にくる言葉を推論しているに過ぎない」ということが強調されるが、原理原則を確認するという意味で、改めてオライリー本の質の良さを感じた1冊。
https://amzn.asia/d/a0jdxre
twitterで興味を持った本や、kindle unlimitedで読める本を順々に読む流れが多かった。
こうしてみると、読んだ量が少ないなと思う。
技術ブログや、技術記事を読むことも多いので、読んでるものは書籍や雑誌、漫画だけではないが、年に30冊ほどしか読めないとしたら、人生で読める本は限られてるな。と思ってしまう。
連休などでまとまって本を読む時間があると、ずっとこの時間が続けばいいのに。と思うが、人生であと何回そのような時間を取れるだろうか。
狂人たちの世界一周
ハイパーハードボイルドグルメリポート
ChatGPT/LangChainによるチャットシステム構築実践入門
Sugar
RIN
筋トレの科学
脳とココロのしくみ入門
生成AIで世界はこう変わる
AWSの基本、仕組み、重要用語が全部わかる教科書
愛しのアイリーン
ダークツーリスト
誰がために医師はいる
リーマントラベラー
ゴハンスキー
アジア罰当たり旅行
LLMのプロンプトエンジニアリング
HOSONO百景
夜が明ける
敗走記
総員、玉砕せよ
ホンマにオレはアホやろか
ブラウザのしくみ
OSのしくみ
LLM自作入門
まあ、どうせいつか死ぬし
民主主義の死に方
こんにちは赤ちゃん
僕には鳥の言葉がわかる
僕のヒーローアカデミア
会話の0.2秒を言語学する
カウンセリングとは何か 変化するということ
ルーザーズ
逃げる中高年、欲望のない若者たち
ソフトウェアデザイン12月号
映画33本
1. ホールドオーバーズ 置いてけぼりのホリデイ
2024年末に配信されていて、自分は観たタイミングが2025年の年初だったので、2025のベストに入れたが、2024に観ていれば2024のベストに入っていた。
たまたま同じタイミングで同じ場所にいた人間同士が影響を与えあって、すれ違っていくという、人生を凝縮したような映画。
全員が同じ価値観やリズムで動いているのでなく、それぞれのキャラクターがそれぞれの問題を抱えて、それぞれの人生を歩んでいる世界。作り手のキャラクターに対する愛情と丁寧さに感服。
2. ワン・バトル アフター アナザー
云わずと知れたPTAの最新作。
とにかく最初から最後まで全くテンションが落ちずに突っ走っている映画。
冒頭のタヤナ・テイラーが高架を歩いてるシーンからテンション爆上がり。レオ様はもちろん、デル・トロや、チェイス・インフィニティ、そしてショーン・ペン！みんな最高！
これだけ楽しい映画で、そして家族の話という、最高の映画。
3. ウィキッド ふたりの魔女
映画館で観て正解だった映画。
エンタメ作品として面白いのはもちろん、すごく政治的な映画に観えた。
多様性を排除する動きや、弱者に優しいということで人気を得ようとしたり、そういったある種のポピュリズムに容易くなびいでしまう人々など。
実際にいまのアメリカで起きていることが描かれていて、多様性と現アメリカ政権との間で揺れ動くディズニーから公開されたこと自体に意味を持っていると思う。
2025年はかなり良作に巡り会えた年だった。
ベスト3から溢れたものの、教皇選挙、落下の解剖学、陪審員2番などベストに入ってもおかしくない作品がたくさんあったし、青春ジャック、アイ・トーニャなど心にささる作品もあった。
2026は映画を観る時間がめっきり減りそうだが、人生の糧になる作品がたくさんあって、安価に享受できるわけだから、今後もちゃんと観て行きたい。
- ホールドオーバーズ
- マイオールドアス
- 落下の解剖学
- ミナリ
- ノーアザーランド
- アノーラ
- 教皇選挙
- ウィキッド
- アプレンティス
- 1987，ある戦いの真実
- ソウルの春
- 12人の怒れる男
- ツインピークス シーズン1
- ツインピークス シーズン2
- スーパーマン
- 猿の惑星 キングダム
- 密輸1970
- 青春ジャック 止められるか、俺たちを2
- 忍たま乱太郎 ドクタケ忍者隊最強の軍師
- SHOGUN
- ザ·ホエール
- アイ、トーニャ
- 永遠の門
- ドリームシナリオ
- 関心領域
- スープとイデオロギー
- ワンバトルアフターアナザー
- ブリジットジョーンズの日記
- ハウスオブダイナマイト
- 聖なる鹿殺し
- 陪審員2番
- ギルバートグレイブ
っていうのよくありません？
自分はめちゃくちゃあります。
ということで今回は前に勉強したけど、ふんわり理解していたので再度勉強し直す。をやってみました。
OIDC（OpenID Connect）とはOAuth 2.0を拡張してユーザー認証を扱えるようにしたもので、クライアントがOpenIDプロバイダーに対してIDトークン発行を要求した際の、リクエストとレスポンスの形式を標準化したプロトコルのこと。
具体的には下記の手順でIDトークンを発行している。
1. クライアント → OpenIDプロバイダー
IDトークンを要求する。
2. OpenIDプロバイダー → ユーザー → OpenIDプロバイダー
OpenIDプロバイダーがユーザーに対してログイン画面などを出して、ユーザー認証を行う。
3. OpenIDプロバイダー → クライアント
認可コードを渡す。
4. クライアント → OpenIDプロバイダー → クライアント
認可コードと引き換えにIDトークンを発行し、クライアントに返却する。
だけだと、分かったような分からないような感じなので、AIに頼んでどういう値を受け渡ししているかをシーケンス図にしてみた。
※ OIDCだけでなく、アクセストークンの発行も兼ねたシーケンスになっていますが、実際はIDトークンとアクセストークンを同時に発行することが多いと思うので良しとします。
②～⑦までの一連のやり取りでIDトークンを発行されていますね。
ただ、そもそも
JSON Web Encryption。
JWTを暗号化して中身を秘匿するための仕様。
JWSよりも高いセキュリティ要件が発生する環境で採用される。らしい。
ユーザーの認証情報をJWS形式(もしくはJWE形式)でJWTにしたもの。
上記のJWT, JWSなどの説明については全人類がお世話になっている下記記事で分かりやすく説明されてます。
IDトークンが分かれば OpenID Connect が分かる #OAuth - Qiita
OIDC（OpenID Connect）とはOAuth 2.0を拡張してユーザー認証を扱えるようにしたもので、クライアントがOpenIDプロバイダーに対してIDトークン発行を要求した際の、リクエストとレスポンスの形式を標準化したプロトコルのこと。
IDトークンとはユーザーの認証情報をJWTにしたもの。
