2026年9月の振り返り

9月を振り返った時の備忘録。

天秤を水平に保ったまま走る

プライベートでは週末に家を離れて妻と牛込神楽坂へ。美味しい料理を食べて落ち着いた街を散策すると充実した休日を過ごせたなと感じる。週明けの仕事でオフィスや篭りきりになっても自然と飽きずに集中できるようになったので週末の過ごし方は重要だと思った。

仕事時間以外はビリヤニやアクアパッツァなど簡単にできてアガる自炊をしたりランニングで体を動かしたりと、あえて仕事と離れたことを行うことでプライベートと仕事の両方で充実感のスパイラルが生まれている気がする。

また、開発でプログラム書くだけだと情緒がないなと飽きてしまうが、技術書典の表紙デザインのブレストやYANSでの国内会議でのポスター発表など他の活動に主体的に関われている時の方が開発にも身が入る。

これまでは仕事のやりすぎた反動で休日寝て過ごしたりといったことも多かったが、逆にプライベートを充実させたり仕事の中でも普段と異なる業務を行い天秤のもう片方のバランスが取れた状態で走っている方がパフォーマンス・QOLともに高いと感じている。

牛込神楽坂で食べたピザ

自炊で作ったビリヤニ

buildersbox.corp-sansan.com

自分らしくいつも自然体でいる

仕事でも普段の自分と変えずに自身の悪い癖も出しながら他者と関わっていくのが心地よくて力を発揮できる。もちろん最低限のマナーや礼儀作法は踏まえた上でだが。相手にも気を使わせないのでお互いにとって良い。どこか繕っている人間には魅力がない。

この本を読んでそれに気づいた。勢いでこの著者が出していたシリーズの本は全部買ってしまった💸

自分をいかして生きる (ちくま文庫 に 8-2)

インパクトにこだわる

自分のいるR&DはROIが高いことに注力するための組織だが、コーディングエージェントが便利すぎてつい細かいアラート対応の修正や評価ツールの修正PRを投げてチームのレビュー負荷を上げてしまい本来注力すべきOKRタスク以外の稼働を過度に増やし過ぎてしまっていた。

チームとしてROIの高いOKRタスクに向き合うには意図的にそれ以外のタスクはissueに切っておき優先度を下げて後回しにしておく必要がある。

もちろんこれらの溜まったチケットはずっと放置しておくのではなく、Qの終わりなどに対応期間を設けておき、コーディングエージェントに投げて一括で対応するなどする。

Measure What Matters（メジャー・ホワット・マターズ） 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR (日本経済新聞出版)

いじわるだと感じた文字の裏には他者の善がある

SlackやNotionなどのツールで非同期に厳しいコメントなどを貰った時は実は悪意を持っている方が少なく実際対面で会話してみるとそうでないとわかることが多い。

指摘は実は良かれと思ってしてくれる善の行為で、非同期のツールでは伝え方・受け取り方が難しいだけなのかもしれない。

NO RULES

CTOがおすすめしていたのでNetflixの組織文化を記した書籍であるNO RULESを読んでみた。

目指している組織の方向性が理解できて良かったのと、後腐れなくFBし合える文化にできると組織内のメンバが互いにミックスアップできて良さそうだと思ったので実践してみている。

やってみるとFBするだけなりがちだが、耳が痛いFBを受け入れる側の意識がより大事になるのだろうなと思った。

良い文化なので浸透していくと良いが、特にFB受け入れる側の意識は自然と浸透する類のものではないので難しいなと思った。この書籍をおすすめして読んでもらうのが良いのかな。

NO RULES(ノー・ルールズ) 世界一「自由」な会社、NETFLIX (日本経済新聞出版)

今年のテーマ

2026年のテーマは「循環と俯瞰」であった。それぞれについて振り返る。

carnavi-blog.hatenablog.com

循環

毎日の成長サイクルを作るために現在以下を継続している。

1. 朝日光を浴びながらランニング
2. 運用しているエンジンのミス・アラートへの対応
3. 価値観・目標 を定義し日記に記載しておいて毎日振り返り自身の行動がそこにアラインしているかを確認する
4. 社内の論文読み会への参加

できていないこととその理由は以下。

• 1日の中でメインタスクの間に サブタスク を挟んで飽きを防止

→ランニングをやっていると集中力が保てるようになりメインタスクを継続できたのでサブタスクへ切り替える必要がなくなったため。

• 通勤時間中 feedly で技術記事チェック / slackのtimes chなどに自身のメモを添えて投稿

→ feedlyは平日毎日見ているが、毎日AIで自動収集させてサマったAIデイリーニュースなるPDF投稿をしていたので自分のメモは添えていなかった。今後も収集した技術記事にいちいちメモを添える必要はないと思うもののテックブログ記事投稿・ポスター発表・論文発表などのアウトプットはもう少しやった方が良いと感じるのでそこは力を入れていく予定。

俯瞰

現在も作業していると肩に力が入ってしまって視野狭窄になることが多い。

少し疲れてきたくらいのタイミングで我に返れたあとは意識して脱力できるようにはなった。

Clean CoderにもゾーンやFlow状態は視野狭窄になり俯瞰できなくなった状態で作業して結局手戻りが発生するといった旨が書いてあったので、ゾーンに入りそうになったら意図的にキャンセルするようにしてみようと思う。

Clean Coder　プロフェッショナルプログラマへの道 (アスキードワンゴ)

結果を出すための「脱力」

はじめに

頑張ってるのになかなか結果出ない。いまのいままでそう思ってきた。

しかし最近脱力をすることでうまく行くようになってきたので書き記しておく。

脱力すると何がいいのか

「脱力する」ということは「力まない」ということ。

そのおかげで享受できる2つのメリットがあると思っている。

1. エネルギーを節約できる

2. ものごとのコツをつかみやすくなる

1. エネルギーを節約できる

なぜあの人は夕方まで疲れずに仕事しつづけれるのだろう。

なぜあの人は毎日勉強しつづけれるのだろう。

そうおもってきた。

自分とあの人とでは何が違うのか。

それは、うまく脱力をして不要なエネルギーを使わずに一つのことに集中投下できてるからではないか？

脱力できてない人ほどいろんなことに等しくエネルギーを使いがちだ。

• スマホの通知がきたら気になる
• 他の人が自分のそばを通過したら気になり気を遣ってしまう

そんなことをしているとエネルギーが減っていき疲れてしまう。

脱力してこれらを「やらないこと」として決めてしまう。

私はやらないことをうまく遂行するために次のことを実践するようにした。

• 目に入るものはノートPCの裏などにしまって目に入らないようにしてしまう。
• 耳栓やノイズキャンセリングイヤホンで外部の音をシャットアウトしてしまう。
• １日の最初にやるべきタスクからとりかかる

そうすることで重要なことのみにエネルギーを費やすことができて安心できるので、焦ってまた無駄なエネルギーを使ってしまうということが無くなったと感じている。

今ではあの人は無限に体力があるのではなく、これらのような 効率的にエネルギーを使う方法を知っているから継続的に仕事や勉強に取り組めたのではないか と思っている。

2. ものごとのコツをつかみやすくなる

脱力をすると力で解決することができなくなる。

ゆえに うまく自然法則を利用しようとする矯正力 が働く。

ものごとのコツをつかむというのはそういうことだと思っている。

例えば7kmほどランニングするときにふとももやふくらはぎといった足の筋肉をつかって力一杯走ろうとする。

これだと1-2km走っただけでかなり疲れる。

ここで脱力して足の筋肉などを使わずに走るにはどうしたら良いかを考える。

• できるだけ体は垂直にして、体が傾くことで支えないといけなくなる足の筋肉を使わなくて良いようにする。
• 重心を下げすぎないようにして、足で地面からの反発力を受ける代わりに前への推進力として利用できるようにする。

こういった具合に自然法則を利用して、できるだけ楽に長く効率的に走るコツをつかむ。

仕事でも、力んでいるときほど「こうに違いない」とmtg中に凝り固まった発言をしてしまうことがあった。

脱力していると相手の意見を聞いた上で正しいとわかれば、その意見に対して思ったことを率直に返してキャッチボールの中で良い方針を模索できる。

そのように感じている。

（余談だが、私を含むADHDはワーキングメモリが小さいので相手の話を理解しづらく、話の内容を補完するために事前に意見を用意しようとしてちぐはぐな回答になるのではないかと思っている。これも脱力して相手の話をよく聞くようにすることとワーキングメモリを鍛えて大きくするトレーニングで改善していっている気がする。）

脱力するとなぜうまく行くのか

これは 「自然法則という大いなる力を使えているから」 だと思う。

いうまでもないがいろんなことがこれを物語っていると思う。

• 川の流れに抗って泳ぐより川の流れに沿って進む方が効率的に早く泳げる
• 硬い鉄骨で支えようとするよりもと複数の木材で構造的に組み上げたほうが耐久性が高い
• 時間帯によって交感神経と副交感神経が入れ替わるウルトラディアンリズムがあり午前中に集中できる作業をするほうが理にかなっている

しかし「力で無理やり解決できてしまう」ということがこのことを忘れさせてしまい悩みの種を生み出してしまっているのだと思う。

まとめ

話をまとめると、

脱力することで「自然法則という大いなる力」が使えるようになるので結果が出るようになる

と思っているという話であった。

他人と比べて限界を感じている人ほど脱力することをおすすめしたい。

TechLead Conference 2026 powered by connpass 参加の備忘録

イベントについて

https://sansan.connpass.com/event/387148/

テーマ

このカンファレンスではテックリードやテックリードを目指す方を対象としており、次の2つをテーマとしていました。

1. AI時代の設計力
2. AI時代の組織マネジメント

Claude CodeをはじめとするAIコーディングエージェントが台頭する時代で、テックリードとしてどのようにソフトウェアを設計し、どのように組織マネジメントをしていくのかという観点で豪華な登壇者が集まっていました。

タイムテーブル

【ホールA：キーノート/事例セッション】

時間	カテゴリ	テーマ	登壇者
12:30	オープニング
12:35 ~13:20	キーノート	AI時代のエンジニアリングの原則① 〜AIがコードを書く時代に何が重要になるのか	和田 卓人 氏 / タワーズ・クエスト（株）取締役社長佐藤 治夫 氏 / （株）ビープラウド 代表取締役社長
13:35 ~13:55	事例	AI時代のガードレールとしてのAPIガバナンス	草薙 昭彦 氏 / Postman（株）テクノロジーエバンジェリスト
14:10 ~14:50	公開Q&A	AI時代のエンジニアリングの原則② 〜t_wadaさんに直接聞く Q&Aセッション〜	和田 卓人 氏 / タワーズ・クエスト（株）取締役社長佐藤 治夫 氏 / （株）ビープラウド 代表取締役社長
15:40 ~16:20	キーノート	AI時代におけるエンジニアリング組織の変わるべき点、変わらない点	笹川 裕人 氏 / Sansan（株）CTO
17:05 ~17:35	ライトニングトーク（LT）	テーマ：「TechLeadやチーム開発に関わること」
17:45 ~18:25	キーノート	変化の速いAI時代に、テックリードは何から見直すべきか	広木 大地 氏 / （株）レクター 代表取締役九津見 真太郎 氏 / （株）ビープラウド 取締役
18:30 ~19:50	交流会	お酒や食事を楽しみながらのエンジニア交流会

【ルーム：ショートトーク】

時間	カテゴリ	テーマ	登壇者
15:00 ~15:15	マネジメント	LLM時代の検索アーキテクチャと技術的意思決定	澁井 雄介 氏 / （株）LayerX
15:25 ~15:40	マネジメント	AI時代における具体と抽象の往復 - 日常にチャンスがある	そーだい / 曽根 壮大 氏 / （同）Have Fun Tech 代表社員
16:20 ~16:35	アーキテクト	AI時代における技術的負債への取り組み	重岡 正 氏 / （株）ROUTE06 取締役 CTO 兼 共同創業者
16:45 ~17:00	アーキテクト	「責任あるAIエージェント」こそ自社で開発しよう！	みのるん / 御田 稔 氏 / KDDIアジャイル開発センター（株）テックエバンジェリスト
18:30 ~19:50	交流会	お酒や食事を楽しみながらのエンジニア交流会

全体を通して印象に残った主張

1. AI時代もコードの内部品質を高めていくことが重要
2. AI時代のボトルネックはコードレビューなので育成が大事
3. トレンドワードに踊らされず本質的な課題に向き合っていればそこまでやることは変わらない

AI時代のエンジニアリングの原則① 〜AIがコードを書く時代に何が重要になるのか

和田 卓人 氏 / タワーズ・クエスト（株）取締役社長

佐藤 治夫 氏 / （株）ビープラウド 代表取締役社長

最初にカンファレンス主催 connpassの運営会社の社長である佐藤さんより、これまで大事にしてきたエンジニアリングの価値観についてお話が始まりました。

エンジニアリングの前提

開発期間より運用・継続開発の方が圧倒的に長いため、長期的な保守性・変更容易性が重要。

これはSaaS会社のエンジニアとして働いていると本当にそうだなと思います。

エンジニアリングの価値観

インサイドアウトで品質を高めるのが大事。

目先の開発スピード重視は悪。プロセスごとに品質を高める必要がある。

V字モデルの開発ライフサイクルを開発の地図として持ち、早期対応を行い手戻りをなくす。

ソフトウェア開発におけるV字モデル

引用元：https://service.shiftinc.jp/column/10905/

特に、ソフトウェア開発の基本であるV字モデルによって早期対応することが工数削減のためにも大事であると主張されていました。

例えば、要求仕様書に誤りがあるとする。

その修正にかかるコストは、

• 設計のタイミングまで残っていると5倍かかり、
• コーディングまで残っていると10倍かかり、 ...

というように、修正が後になればなるほど倍倍ゲームで工数が増えていきます。

これはウォーターフォールだけでなく、アジャイルにも当てはまる話だと主張されていました。

そしてこれはAIを用いた開発にも生きてくるのではないかと考えている旨を話されていました。

確かに、Claude Codeを使ってコードを書いていると、仕様が曖昧なまま指示を出したコードが書き上がるのを待つよりも、最初にある程度Planモードで仕様を固めた上で実装に移ったほうが効率的に開発が進むことが実体験としてあったので、これはAI時代のエンジニアリングにおいても有効な価値観であると感じました。

また、今回佐藤さんからt-wadaさんへオファーした理由として、「The Software Development Lifecycle is Dead (boristane.com/blog)」という記事を引用して、本当にこれまでの開発ライフサイクルがなくなるのか気になっておりオファーされたということで、この話を出発点として、佐藤さんとTDDで有名なt-wadaさんとの対談セッションが始まりました。

基本的に、佐藤さんからの質問に対して、t-wadaさんから回答する流れで話が進んでいきました。

トークセッション

話されていた内容についていくつか紹介したいと思います。

• TDDはAI Agentの時代にどう変わっていくのか？

  • 確かにほぼ人間はコードを書かず、AIが書くようになった。特にAIはV字モデルの実装-テストの谷の部分が得意。
  • しかし、それは主体だけが人間からAIに変わっただけであり、TDDは変わらずAIがやっている。
  • これまでTDDを普及するために様々な取り組みをしてきたが、AIを使うことでTDDをするコストが下がり、2025年には皮肉なことに何の取り組みもしてないのに最もTDDが日本に普及した年になったと思っている。

• TDDがAIで流行った要因は？

  • 必要工数を潰せたからというのが大きい。TDDの学習コストはそれなりにあるため。例えばテストから先に書くのに慣れない人もいる。それをAIがやってくれるようになりテストを書く実装コスト含めて減ったというのでTDDをやる人が増えたのではないか。
  • むしろTDDで書くテストより自動テスト（リグレッションテスト）は増えている。特にOSSなどではAIがゴリゴリPRだしてくるので絶対やってくれという感じで、コーディングエージェントが何かをいじると何かが壊れるというのを防ぐためでもある。

• エンジニアはコーディングエージェントにどう関わっていけば良いのか？

  • やり方は二つ
    1. 同期的に見守る・伴奏する
    2. 非同期で任せる
  • 1.同期的に見守る・伴奏する
    • Claude Codeは厳密にはTDDをやっておらず、テストファーストプログラミングをやってるにすぎない
    • テストファーストプログラミングとは、最初にテストをばーっと作って、その後テストを通過するようにコードを書く方式。TDDとくらべて一度に更新する歩幅が大きいという違いがある（一回で出てくるdiffが違う）
    • 作業が速い一方で、間違った大量のコードを書いてきて指示をしなおしてまた大量に書き直してもらうというような無駄を増やすリスクもあるのでTDDのほうが手戻りが少ない
    • Claude CodeなどのコーディングエージェントにTDDをしてもらうには「（red, greenの）（twadaの）古典的なTDDでやってください」というと人間がレビューしやすいやり方でやってくれるので良いらしい
    • このように人間が即時介入する体制を作る方が手戻りが少なく伴奏開発ができるので、AIとペアプロしてる感じでやってるとのこと
• その際人間がボトルネックにならないのか？
  • ペアプロで言うと人間に合わせる感じになるので、500行とかAIが出してくると人間が追いつけない。
  • テストコードをAIに書いてもらうのも少しはコードレビューの役割を担えるがちゃんとソフトウェア開発をやろうとするとまだ人間のレビューが必要。
  • この人間律速になる課題をどうするのかだが、t-wadaさんのやり方はauto acceptモードにして見守りながらみるだけなので止めないのでそこまで遅くはないとのこと。そして最後改めて書き上がったコードをあらためて見て確認しているとのこと。
  • （これは懇親会でt-wadaさんに直接聞いた話だが）Claude Codeでコード書いてもらうときは、ターミナルのメインのペインにコアな部分を見る必要がある開発を「同期的に見守る・伴奏する」スタイルでやりつつ、同時並行で確認が不要なテストの網羅性を上げるようなタスクを2,3個「非同期で任せる」スタイルで完全にまかせて書かせるというやり方でやっているそうでした。
• 内部品質の観点でのレビューは必要か？単体テスト書いてれば内部品質はどうでも良いと言う意見もあるがそれについてはどうか？
  • 理解容易性と変更容易性の2つの観点で内部品質は重要だという意見だった。
  • 理解容易性の観点で、モジュール性を高めておかないと開発効率が落ちる。
  • これは人間とAIのコードへの理解しやすさは今の所変わってないためで、この点に関しては今のところひと安心しているとのこと。
  • 変更容易性の観点では、コードを変更するための主体が人間からAIに変わったので、ここだけものすごく変わった。
  • ある程度のところまでは理解容易性と変更容易性は共に高まり続けるが、どっかのタイミングで理解容易性と変更容易性のトレードオフが出てきて、そこでどちらをとるのかという介入をするのがテックリードの仕事とのこと。
• 内部品質が重要だと言うことは変わらない？
  • 人間がコードを読み書きする限り変わらない
  • 変更容易性よりも理解容易性が大事みたいなパワーバランスの変化はあるかも
• 詳細設計・仕様駆動設計をAIとどうやるか？
  • 詳細設計はAIとplanモードなどでやる
  • 要件定義や企画はやりやすくなった
    • 試行錯誤のための物的生産性が高まった
    • ここ2年で仮説検証・プロトタイピングなどが簡単になって探索がやりやすくなった
    • 企画段階で動くシステムを持っていくことができるようになった
• コンテキストエンジニアリングは取り組んでる会社はある？
  • 要件定義のアウトプットをプレーンテキストでやるようになった（これまではエクセルなどだった）
    • その上でコードの近くでやるようになった(docs/など)
    • コードを管理するように文書も管理するようになった
• さいごに
  • AIは増幅器である
  • 企業の業績とソフトウェア開発力は因果関係がある と言う旨のレポートがあった
  • ソフトウェア開発が苦手だとより混乱を招く
  • AIの前はDXと言うバズワードで踊ってた
    • コンテクストが大事という話はこの頃から言ってた話で結局増幅器であると言うことが言える
  • とはいえアンラーニングしないといけないことが出てきた
    • 人間以外がソフトウェアをいじる時代
    • 考え方を変えて良いところ
      • 変更の主体が人間ということ前提で考えられて来たことはアンラーニングして良いところ
      • ex. 「コードを人が書く」ことはすでにアンラーニングされつつある
    • 大変なところ
      • 認知負債
      • コードレビューしてれば相手が理解してることが担保されてたが、今はAIが書くのでPRあげた人が理解してるか分かってない
      • 大きな障害が起きたタイミングで、この認知できてるかと言うことをどのようなメトリクスで追っていくべきかなど議論することになるだろう

AI時代のエンジニアリングの原則② 〜t_wadaさんに直接聞く Q&Aセッション〜

和田 卓人 氏 / タワーズ・クエスト（株）取締役社長

佐藤 治夫 氏 / （株）ビープラウド 代表取締役社長

• AI時代もプログラミングは学んだ方がいい？
  • yes。AIは増幅器でしかない。労力は外注できるが能力は外注できない
  • ここ2,3年で学ぶスピードは上がってきてる
• Auto Acceptをしてると言う話だがリテラシー高くないメンバには難しいかなと思ってます。セキュリティ観点はどのようにクリアしてる？
  • 選択肢
    • 他の人のレビューで担保
    • セキュアコーディング周りのSKILLでセキュリティを担保
      • セキュリティエンジニアはテストエンジニアより少ないので仕組みで解決していきたいため
  • 基本的にチームプログラミングをやっていくべきだと思っている
    • 全ての専門性を持っている人はいないので得意分野を持ち寄ってチームで開発することになる
  • リテラシーを上げるには、「仕組みで防ぐ + 教育」が組み込まれないといけない
    • コードレビューがこれまでは成長要素であった
    • モブプログラミングでセキュアコーディングに強い人がAIに指摘している様子を目撃させるとか
  • マウスを使わずキーボードだけで操作しているのを目撃することでたくさんの学びがある
    • これからは/コマンドでショートカットできるとかを学ぶなど
• コーディングエージェントのコード、テストを全てチェックしている？
  • チェックしている。理由はそういう性格だから（趣味の領域とのこと 笑）
  • コードレビューはボトルネックだがコーディングはボトルネックじゃない
  • コードを全行検査しないでもいいタイミングは出てくる
  • テストコードを書かせるとき、網羅性を報告させて中身は見ないみたいなことをやってるチームもある
    • テストコードよりテスト結果の方が情報密度が高いので先にやれるという意味では良い
• リソース効率を上げても意味ないと言う話を深掘りしてほしい
  • 人増やして並列開発できるようにしていった
  • しかしマージするシニアエンジニアは少ないのでレビューに徹してその人はいいコード書けるのに書けないと言うのでボトルネックになってた
  • レビュワーを増やさないと→成長してもらうための育成が大事
• エンジニア新人教育をどうしていくべきか？
  • 小さなステップアップをしてもらうことはできるのに、それをやると他者に遅れをとるみたいに思われてることの方が問題
  • エージェント登場でみんな目の色変わってしまった
  • 教育は時間かけてもいい
  • 教育によって今のスピードは下がるかもしれないが将来の質とスピードを上げることができる
  • 基礎をちゃんと教える方が割りにあうと言う感じの風潮になってきてる
  • 新人だったら生産性も求められないので、だったらちゃんと基礎をやってもらおうと言う雰囲気になってきた
  • 新人エンジニアを手で書いてもらってるがAIをOFFにするとみんなびっくりするくらい書けない
• 理解容易性と変更容易性のトレードオフはどう言語化してスキルに落とせばいい？
  • 基本的には両方上がっていくもの
  • トレードオフたかまっていった先に起こるもの
  • 「ソフトウェアの結合バランス」と言う本にバランスが書いてる
    • 人はやると疲労するが気づきを得ることができる
    • AIはそれがないので馬力を出せばなんとかなるという設計が入ってきてる
  • 人間に頼めないものもAIなら無限の体力があるので頼める
  • SKILLの設計判断
    • good badのパターン列挙することがある
    • 迷ったらそっちじゃなくてこっちをとると言うのを入れる
    • プロジェクトによる判断をSKILLに入れる
    • ex. デザインパターンで理解しやすいけど変更しにくいものがあって、どっちかというとこれをとるみたいな
    • AIの変更力を活かして理解できる方を取るって感じかな
• AI興味ない層にどうアプローチすればいい？
  • 伴奏しつつSKILLsで共有するなど
  • 使えないとやばいとかの危機感ではなく、損得、苦楽でアプローチするのが大事
  • うまく使ってるのをチームで共有していく仕組みが大事
• 3rd partyライブラリの今後の価値は？サプライチェーンアタックも気になってて大規模でないものは内製する機運があるため
  • 3rd partyライブラリやOSSは設計、ドキュメントがしっかりしていて、ユーザ数が多いのが価値だった
  • しかしサプライチェーンアタックのリスクにより再実装する流れは仕方ないかなと思っている
  • テストコードがあればAIに再実装できることがわかってしまいモラルが崩壊したのは悲しいことだけど
  • 短期的には3rd partyライブラリの使う部分を切り取って、内製してアップストリームを追いかけながらメンテナンスと言う感じになってる気もするが、中期的にはどうなってるかわからない

AI時代のガードレールとしてのAPIガバナンス

草薙 昭彦 氏 / Postman（株）テクノロジーエバンジェリスト

Postman（株） 米国が主体のAPIのためのプラットフォームを作ってる会社

パラダイムシフト

• 人間中心のDX(Developer Experience )からAIエージェント中心のAX(Agent Experience)へ
• コーディングエージェントによるDevin, Calude Code
• APIの場合はAIがユーザになることもある → AIが使う場合を想定した設計が必要
• 逆にAIが作ったAPIをAIが使うこともある
• AIが上手くやってくれるからAPI管理は不要というのは誤解
• 現実は逆：APIが無法地帯であればビジネスリスクは指数関数的に増大
• 技術リーダーの悩み：実装スピードは上がるが安全性と統制（ガバナンス）をどう両立するか

リスクの正体

• OWASP Top 10 for Agentic Applications(2026)
  • これのLLM版もある
• ASI: Agent Security Issue
• ex. ASI01: プロンプトを通して目的をすり替えてしまう

• API観点
  • ASI02, 03, 08
  • エージェントは合理的な手段を取るので突破しようとする

信頼の境界（Trust Boundary）の再定義

• NIST AI RMF(Rist Management Framework)
• ゼロトラストアーキテクチャと言う有名なものをAIに特化させたもの
• APIはAI暴走を止める門番であるべき
  • 疑問：具体的には？

AI開発に友愛API大爆発と技術負債の制御

• 発見の困難性
  • 似たようなAPIをエージェントが次々生成してどれが正解かわからない
• 責任の不透明
• 再利用性の欠如

両輪で支えるガードレールの全体像

• 静的なガバナンス
  • 地図の提供
• 動的なガバナンス
  • 運用時にゲートウェイで行うような管理や強制停止など
• この2つで開発速度を落とすことなく安全性を担保

APIは知的なフィルターへ

• 動的なガバナンスの方
• AIエージェントの運用のためのガードレール4要素
  • Permission, Approval, Audit, Kill Switch
• 異常検知したら物理的にスイッチを切るなど

意図の検証とセマンティックバリデーション

• 単なる型のチェックから「意味のチェック」へ
• 例えば、実行前に「本当に100万円を送金する必要があるのか」などをAIにチェックさせる

シフトレフト・ガバナンス

• 例えて言うなら下流で汚染水を浄化するくらい遅い
• 後になればなるほど対応コスト・リスクが増加する

AI-readyなAPIの設計図

• OpenAPIだけでなくメタデータの充実とカタログが必要
• APIのdescriptionはAIへのプロンプトそのものになって来ている

シナリオのテストとディスカバリ制御

• APIをデプロイする前に、エージェントに仕様書を渡して正しく動けるか、を動的にテストする

Postman: AI-ready APIプラットフォーム の紹介

• 脆弱なAPIを世に出る前にチェッカーで防ぐ
• シミュレーションでAPIの堅牢性を事前検証
• APIをAIが使いやすく変換するMCPサーバも提供

まとめ

LLM時代の検索アーキテクチャと技術的意思決定

澁井 雄介 氏 / （株）LayerX

• 研究開発部ともう一個のエンジニアリングの部も澁井さんが立ち上げたらしい

今回のテーマ

（人間のための検索と比較したときの）AIエージェントのための検索

人間の検索

• 1つの検索エンジンを使って、大量のデータの中から欲しいものを探す

LLM時代の検索

• 2つの側面がある

  • LLMを使った検索
  • LLMのための検索

• LLMやAIエージェントを取り巻くデータ

  • 検索に使うデータが大事で次のようなものがある
    • Document
      • pdf
    • Context/Memory
      • うまくいったものを記録しておくもの。これも検索対象
    • elastic search, slack, notionなどのtools, Skill, MCP
      • MCPなども検索対象

• GPT-5にグラフを入れて簡単なプロンプトだけでリッチなjsonが抽出される

  • 特にグラフの読み取り（今までは人間しかできなかった）

• LLMを駆使したスライド検索の例

• 2つが違う
  • 人間のための検索
    • 人間がGoogle検索するときが良い例
      • 適切な満足する1件が見つかればいい（人間のための検索は1つに絞るということが重要だった）
      • 納得性を重視
      • 直感的なUIがよい
  • AIエージェントのための検索
    • 判断根拠にするエビデンスを突き止めるために構造化と検索の繰り返しが必要になってくる

人間のための検索とAIエージェントのための検索

• 構造的、チェーン検索　が特徴

• 「エージェントというのはソフトウェアですので...」ということを繰り返し言ってた

• AIエージェントのための検索体験設計
  • 人間はメタデータはあまりみないがAIには必要
    • →メタデータを多様に
  • ファセット・フィルタ
    • パラメータと実行結果のログも次の探索に使う大切なデータ
  • ...

まとめ

話の内容のメインはAIエージェントの検索についてで、大事なのは、人間の認知限界に囚われずに構造化させていって更なる階層的な探索をさせるようにすることだよねみたいな話だった

「責任あるAIエージェント」こそ自社で開発しよう！

みのるん / 御田 稔 氏 / KDDIアジャイル開発センター（株）

テックエバンジェリスト

AIエージェントなぜ作る必要がある？

• 既製品は本当に使い物になってる？
• 正直まだ使い物にならない→ビッグテックが汎用品を出してくるまでの半年〜1年の余白があり、そこで自分で作れると市場で先回りできる
• また次のツール出てきたら乗っかってその空白期間に作って...
• とやっていける組織が強い

作るのは意外と簡単

• lang chain

でもエージェントは問題児

• デプロイして使ってもらおうと思ったら
• ストリーミングレスポンス対応したい
• ...

そんなあなたにBedrock AgentCore

• サーバレスlambda
• ストリーミングレスポンス対応

フルサーバレス鉄板アーキテクチャ

• githubにpushするだけで勝手にCIが読み取ってくれる
• 商用で使えるレベル
• オンデマンドでお金もかからない

デプロイして終わりじゃない

• 改善が...
  • →AWSのお家芸

エージェントにSaaS触らせる時の権限

• Agent Core gatewayでデコレータつけるとよしなに

特定の操作させたくない

• ifとか面倒
• Agent Core ポリシーで設定できる

エラーに対して監視SaaS入れなきゃ？

• ログ多すぎて追えない
• Agent Core オブザーバビリティ
• 裏でOtel回ってる

利用者減ってるけど何が原因かわからん

• Agent Core エバリュエーションで解決
• LLM as a judge

野良エージェント乱立

• AWSエージェントレジストリ

技術は揃った。何が足りない？

• 提案する人が足りない
• お客さんの要件を待ってたらエージェントで何がやれるかわかってないから LLM RAGの案件しか来ない
• なのでできることを示しつつこっちから提案する必要がある
• Vibe商談でその場で作る（FDEっぽい感じ）

おきまりの書籍紹介でFinish

変化の速いAI時代に、テックリードは何から見直すべきか

広木 大地 氏 / （株）レクター 代表取締役

九津見 真太郎 氏 / （株）ビープラウド 取締役

広木さんは「エンジニアリング組織への招待」を書いた人

目次

01 AI活用がチームにうまく定着しない時、テックリードは最初にどこから手をつけると良いのか

• 一部の人はうまく使っているがチーム全体のやり方や成果には繋がりにくい課題がある
• しかし、本質はAI使ってるだけで万能感に満たされがちなエンジニアの方がやばいと思っている
• 強制的にAI触らせるのは、重要な福利厚生だと思う
  • 自発的にボトムアップ的にやってくるのを待つのは遅いのでトップダウンでやらないといけない時がある
  • MIXI時代にスマホアプリ開発のためにスマホ強制的に触らせるということをやった
  • スマホ、クラウド登場など大きなものの話を扱うとき、ボトムアップ的なことやってると手遅れになっているということが多い
  • 号令出してもやり方わからんで止まることもあるのでやり方とセットで推進するのが大事
• AIを使う上で「昔の働き方を矯正しているような使い方」には注意が必要
  • AIエージェントにppt編集させてるのって...という感じが現状としてあったりする
  • ハイテクなのに印刷用に...Excel方眼紙みたいなことになってしまっていることに気づかないといけない
• 次の時代の働き方に合わせたフォーマットを考えないといけない️⭐️
  • pptまとめることも報告用のmtgももう古くて、プロジェクト管理ツールが一次情報ならそれから知りたい人が好きな時に取ってくるべきではないかと考えている（基本的にAIが全てを把握できる状態）
  • 新しい時流が来た時には新しい時代のフォーマットを考えてそこにチューニングすべき
• 組織として推進していくには自然と使わずにはいられなくなる快感を作っていかないといけない
  • 最初に自動テスト書くのは皆んな嫌だが辛いことがあって自動テスト書くようになる
  • しかし一度導入すると便利すぎてもはやそれが当たり前になるので今までの環境に戻れなくなっている
  • AIコーディングなしに戻れない状態に持っていくのがテックリードの役割ではないか
• トレンドに踊らされないようにするにはという話
  • 昔はCIという概念がなく、その時代（jenkinsない時代）でも自動テスト作るしかなかった
    • でも今ではそれが当たり前になった
  • featureフラグがない時代からfeatureフラグ作ってた
    • 当初説明が難しかったが今は名前が付いてて楽
  • 名前がついてからでは遅い
    • （みんなの共通の認知になって名前がつくのでだいぶラグい）
  • ハーネスエンジニアリングというワードもそう
    • 名前つく前からガードレールなんかやってたはず
    • 名前に踊らされず課題の解決に集中するのが大事

02 個人のAI活用を属人的な工夫で終わらせず、チームのやり方として定着させるには、何をしていくと良いか？

• デカめのPJで20人とかでClaude Code使ってやってるとうまくいかない失敗だけが溜まっていってうまくいった事例がたまらず前に進まないことが多い
• しかし10万行くらいまでの個人PJだと色々試せて視座が上がる
• このように小さいPJをやって培った知見や経験を大規模PJの持ち込むのがいい
• この小さいPJの究極が個人単位でやることでこれを属人的というのであればむしろ属人的になった方がいいまである
• 属人的にClaude Codeでやってもらってもコンテクストやドキュメントとして残ってるので問題なかったりする
• そこで得た知見をconferenceやモブプログラミングで共有していった方がいい
• 仕様をコードにしていくとインスペクタよりエッジケースなどのバグ検知が上手かったりするのでそれをインスペクタに追加したりするとか共有知識にしていくとよい
• 最初はどんどん属人化させちゃってよくて節目のタイミングでチームに還元できるようにできてれば良い

03 新しい概念や技術トレンドの本質を、どう見誤らずに捉えるか

• 新しいことほど、ブームがあってみんながよしやろうという時には時間が経ちすぎてしまっている
• 本出されたくらいの時にやろうとなってるとそれはテックリードなの？ってなる
• Anthoropicのテックリードがハーネスエンジニアリングって言ってすげーってなっているが別にガードレールなんて昔からあることで大してすごいことはやってない
• トレンドワードが来ても実は本質はあまり変わってなかったりする
• いくつかの本質を裏に備えているトレンドが来ては去ってを繰り返していて、循環していく螺旋でしかなく地続きであることも多いのでので今やるべきことを抑えていればそこまで身構えずとも良い

（もりあがりすぎてここまででお時間）

感想

全体を通して次のような学びがあったので活かしていきたいと思いました。

• 結局AIにゴリゴリ書かせても手戻りが発生したら意味がないという主張が多かった
  • 企画や設計などの早いタイミングで対応した方がコストが少ないのでシフトレフトで早期対応するのが基本だというのは改めて意識するようになった
• approveするシニアエンジニアのレビュワーの数がボトルネックになるというのはその通りだと思った
  • AIにたくさん書かせてPR出しまくってもレビューできる人の数が結局ボトルネックになるので、レビューできる人を増やすこと = 育成 をしないと将来の生産性は上がらない
  • レビュー側に回る人を増やすためにも日々の業務の中に成長する仕組み・サイクルを作っていくことが大事だと思った（マージのrequired review countを増やす、モブプログラミングの時間を取るなど）
• V字モデル・TDD・SSOTなどソフトウェア開発の知見はAI時代も必要だと思った
  • テックリードレベルの登壇者はみなこの辺りの知見に詳しい
  • これらの知識はClaude CodeでDESIGN.mdなど設計に関するドキュメントを書く際や、実装のやり方を指示する際に乗算的に活きて来る
  • もっと古典的なソフトウェアエンジニアリングの知見に関する書籍や界隈で話題になっている技術記事などを追いかけていきたいと思った

カンファレンスで話題に上がっていた書籍

テスト駆動開発

ソフトウェア設計の結合バランス　持続可能な成長を支えるモジュール化の原則 (impress top gearシリーズ)

アーキテクチャモダナイゼーション【リフロー型】 組織とビジネスの未来を設計する

チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計

エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング

AIエンジニアのための機械学習システムデザインパターン

現場で使える！機械学習システム構築実践ガイド デザインパターンを利用した最適な設計・構築・運用手法

Amazon Bedrock AgentCore 実践入門 Strands Agentsで構築するAIエージェント [AWS深掘りガイド]

最近の悩みと気づき

いつもジャーナリングを紙かobsidianにしてるのですが、メモ書きレベルで同じことを何度も書いてたりしてなかなか整理できていなかったのでちゃんとした文書としてまとめることで思考を整理するために記事にしてみることにしました。 普段考えてることを公開することはなかなか小っ恥ずかしいのですがお付き合い頂けるとありがたいです。

モチベーションが迷子問題

今私はSaaS企業で機械学習エンジニアをやっています。

年末の振り返りからしばらくして、「便利を生み出すエンジニアよりも感動を与える映像演出などのほうが直接的に人のためになるコンテンツを生み出せてやりがいがあるんじゃないか」と少し今後のことについて悩んでいました。

いろいろ自問自答した結果、上記の考え方はそもそも屁理屈で演繹的な類推をしたにすぎず自分が本心でやりたいこととは少し違うことがわかりました。

加えて、「映像を作ったとして、顔の見えない不特定多数に感動してもらってもそんなに自分はうれしいのか？」「それよりは身近な誰かに感動してもらって反応を見れた方が嬉しいのではないか。」「まして一番身近な人は自分なので自分が喜べて相手も喜べるのが理想ではないか。」 と思うようになりました。

別に不特定多数の誰かに感動して欲しいから作るわけではなく、自己満足でもいいから良い作品を突き詰めて作りたい、その結果として誰かが感動してくれた、嬉しい、またいいものを作れるように頑張ろうという順番のサイクルなのかなと。 「作る "何か" は無意識レベルでなんか好きなもの。好きだから勝手に作る。」みたいなものでよいのかなと。

もっというと作品から直接伝わる感動もあれば、誰かが仕事に向き合う過程を通して伝わってくる間接的な感動もあるなと。

そう考えると、作品を作ることやどのような仕事をするかはお飾りにすぎず、今は「要は他人に感動を与えるくらいの何かがしたいのかな」という割と抽象度の高い結論に至っています。

そして感動与えるくらいのことができるようになるには、高い水準の技術力も必要ですし人間性も必要なのでその辺りを高められるように日々意識していきたいと思っています。

プロフェッショナルを目指す

「とはいえ何から始めれば良いのだろう。」

そう思い色々考えましたが、「今はとにかく強みとなる専門性が欲しい。」そう思っています。

「これだけはプロと言い張れて、実際に誰かの役に立てて、その対価としてお金がもらえて飯が食える。」「いろいろはできないけど最低限これはできて役に立てるよ」という自分でいたかったのです。

そうすることでその領域でのプラクティカルな知見も積み上がっていき、より役に立てるようになるというサイクルがまわり、自分の得意と相手の需要がマッチするのかなと思っています。

その結果、感動を与えられるくらいのことができるようになり、それをプロと呼ぶのではないかと。

また、今の中途半端なままでは他の職種に移ったとしても後悔が残ってしまう。それだけは嫌だったのです。

なので、今はML領域、特に会社のドメインと相性の良いVLM領域の専門性を高めようとしています。プロになれるよう鋭意精進しているところです。

（正直ML・VLM領域の専門とするエンジニアは社内に多いですが、個人としてその領域が好きであれば、きちんと事業価値が出せれば誰かと被っても他人は関係なく会社にも貢献してるので問題ないという先輩の教えに共感したので、あまり社内の誰かと被っているからといって、個性を出そうとするあまり目指す領域をずらそうとするのはやめました）

仕事をゲームと思うことにした

「仕事をゲームと思うとか、こいつ仕事舐めてるな」と思われたかもしれません。

しかしこれは仕事を重く見過ぎるあまり身動きが取れない自分をキャンセルするための突貫対応です。

というのもプロとして人の役にたつものを生み出すことを意識するあまり、気づけば「自分はまだまだなんだから土日も勉強しなくては。」と焦燥感に駆られるあまり上滑りした思考になっていました。

こうなると、いざ勉強しようというときに、「やりたくないのに休日にもやらないといけない。でも何のために？そんなに人の役に立って何がしたいの？」と思うようになります。

ましてや重い腰が上がらなくなり結局日々の学習からも逃げてしまう始末。

かといって漫画読んでもアニメみてもyoutubeみてもゲームしてもなんか充実感がない。

結局これらはやるべきことに対する逃避行動でしかなく、私にとって真にやりたいことではないようでした。

もちろん、仕事に対してある程度責任をもつことで、スケジュールを守れるように他のメンバと連携して開発ができたり、そのスケジュール前提でプレスを打つことを計画したりと並列的に動けるので仕事がスムーズに進めるようになるので大事なことではあります。

しかし、責任を感じすぎてプロとしての技量を培っていくことができずに結果プロになれずに結果が出ず相手のためにもならないのでは本末転倒です。

社内で楽しそうに働いていて優秀な方を見たり、実際に話を聞いていると、仕事を課題解決という一種のゲームのように捉えていることがわかりました。これがちまたで聞くゲーミフィケーションというやつかもしれません。

最初は仕事をゲームと思うと碌なことが起きないのではと少し怖かったのですが、背に腹は変えられないので、思い切って試しに仕事をゲームや趣味にちかいものと思うことにしてみました。

ゲームから充実感を得られないのは、ゲームのステージをクリアしても現実世界ではなにも得ることができず虚無になるからです。ならば、仕事をゲームにすれば成果をあげることで人の役に立てますし、役に立ち続けていて場昇格し給料をあげることもできます。現実世界で得るものがあるのです。

それに、ゲームといっても遊んでいるわけではなく、どうしたら目の前の課題を解けるのかを楽しみながら解くということかなと解釈しており、楽しめると続くので仕事も楽しめるようになります。

ゲームと思うと気が楽になり、変に力むこともなく、とはいえ合理的に進めようとなるので、ハードルの低さとパフォーマンスが割と両立する気がします。

このように考え方を変えてみると今まで仕事のために学習しようとしたが読めていなかった本がふしぎとすんなり読めたのです。

どうやら、プロを目指しているにも関わらず読めていない自分への罪悪感、それによる自分の中での自己嫌悪・自己悲観に脳のリソースを使ってしまい、読む前に私の精神エネルギーが尽きていたことが原因のようでした。

または、読もうとページを開いても、他の人に遅れをとっているので早く読み進めないと追いつけない。と焦って内容が頭に入ってこなかったことも多々あります。

このように、責任感を持ちすぎると良くないこともあるようです。

ゲームのように捉えて責任という重しを取っ払ってみるとフッ軽に考えれて行動に移しやすくなりました。

（仕事終わりの電車などで疲れてる時に読もうとしてもやはり頭に入ってこないので土日もそうですがやはりある程度リフレッシュのための休息日は必要かなと思いました...）

構造を理解する

また、今までは本を読んでも暗記のように読んでしまい技術書を読み終えたとしてもあまり実務で活かせていなかったので、次も読もうと言うモチベーションがなかなか湧きづらい状態でした。この頃はうまくインプットとアウトプットのサイクルが回っている気がしませんでした。

あるとき先輩から「構造を理解すれば課題がわかるので解決策が見つかるはずだ」という教えがありました。これは自分にとっては目から鱗でした。

それなら 読書のようなインプットから構造を理解して解決策がわかれば実務でも活かせる とおもい、実務に活かして良い結果が出せればまた次の本を読みたくなるというサイクルが回る と思ったのです。

インプットとアウトプットと2つの分かれたものと捉えるのではなく、「構造がどうなってるかみてみよう」「そのような構造になっているのであればこうすればいいよね」というシンプルな地続きのことなのだ と捉え直す良い機会でした。

それ以降は、焦らずじっくり構造の理解を深めることを意識して技術書を読むようになり、自然と「このような構造なのであればなぜここはこうなってるんだろう。自分で試してみたい。」といった内発的なモチベーションも生まれてきました。

深く理解すると「あー、そういうふうになってるんだな」というアハモーメントがあり、勉強にハマったころの学生時代はこんな感じで思いの外楽しいものだったよなとその頃の感覚を思い出すことができました。

仕事で早く結果を残したいと日常業務しかやらずに学びをおろそかにすると、将来の求めている結果は得られない。そういう時こそあえて立ち止まり、なぜそうなっているのかという構造、いわば基礎を時間をかけて身につけて積み上げることこそ、最も早く結果を持続的かつインクリメンタルに出していく唯一の方法なのではないかと思っています。

実際、今流行りのClaude Codeに指示をする際にもTDDやSSOTといった古来からの基礎的な知見が役立ちます。

トレンドが現れた時に落ち着いてその技術の裏側を見ると、基礎の知識が螺旋のように連なってできたものだということがよくあり、今基礎を身につけることで将来またトレンドが現れた際も理解の助けになるのではないかと思っています。

ということで最近の悩みと気づきをつらつらと書いていきました。

後で見返してこの時はこう対処してたんだなと振り返るための備忘録としたいと思い書いてみたのですが、同じような悩みを抱える方への何かしらの気づきがあれば幸いです。

それでは！

デスクワーク用のメガネ作ったら目の疲れが嘘のように消えて仕事が捗りまくった話👓

今からこれを作りに行く https://t.co/991PoT9Fee

— りょうちん (@ryochinsns) 2025年10月21日

近距離にピントが合うようにできていてデスク離れると逆に遠くがぼやけるので離席時の付け替えはすこし面倒ですが本当に疲れなくなるのでおすすめです😎 https://t.co/BQWEhOgokG

— りょうちん (@ryochinsns) 2026年1月26日

大谷が使ってる17万円のマットを使ってみた感想

⭐️大谷マット１週間使ってみたレビュー

• 商品は「エアーSX（レギュラー）シングル」
• シングルで17万円するので「うわー高っか」と思ったが1日の1/3を過ごすとこだし10年くらい使うと考えたらまぁ...と思って買った
• 最初に悪いところを言っておくと、「ゲーミングマットレス」みたいな色していてそのまま使うとダサいのでマットレス用のラップカバーを別のお店で買うなどは必須
• 実際2万円くらいのマットの時は腰が痛くなって起きてたけどなくなった（ある漫画家がこけしを枕にしてると痛くなって寝過ぎず起きれていいみたいな話を聞いたことがありそれはそれでいいかなと思っていたのでなかなか買い替えなかった）
• 寝返り打つ時に肩が入りやすく寝返り打ちやすくなった（寝てる時なので覚えてないが一般的に人は20回くらい寝返り打とうとするらしいので、寝返り打ちたいタイミングで打てないと特定の部分に圧力がかかって疲労が取れないとかはありそうなので大事かも）
• 気持ち睡眠時間が減ったので時間を買った感じになっている（いつもは7.5hが6hくらいになった）
• 値段は高かったが、今のところ買って後悔はしておらずいい投資だったかなと
• 妻は同じ西川シリーズの「エアー01 SE（レギュラー）シングル」使っててこちらは5万円くらいだけど以前自分が使ってた2万円の別会社のマットレスと比べてかなりねごごち良かったのでもう少し安いシリーズでもいいかも（かれこれ8年くらい使えてるらしくこれが良かったのがきっかけで西川にした）

⭐️同じく西川の枕レビュー

• 商品は「エアー4DX （High）」
• ポリウレタンのニオイが強く気になる人は気なりそう（自分はガソリンの匂いとか好きなタイプなので気にならなかったが）
• 3.7万円とまぁお高い...
• いい感じに中央部分に行くにつれて凹んでるので首元にフィット感あって良い
• カバー外すとポリウレタンの層があり1cmくらいの単位で2段階くらい高さ調節できて個人の心地よい高さに調整可能で良い（自分は高さ調整できるということでHighを買ったが1cm下げてちょうど良いくらいだった）
• 自分は体圧分散のヒートマップを見て頭への負担が無くなりそうな4DXにしたが、他のシリーズも高さ調整できて1万円くらい安かったりするのでそちらでも良いかもしれない

P.S.

ライトグレーのマットレス用ラップカバー（8800円と高いのに相対的に安いと思わされてしまい...）も買ったがおばあちゃんの下着みたいな色してたので返品を試みたが自己都合では返品できず泣いた😭

2025年振り返り

機械学習エンジニアをしているかーなびです。

1年という時間は長いものですが、振り返ると短いなと思います。 毎年あっという間に過ぎ去ってしまい何をしたんだっけ？となりがちなので備忘録的にまとめていこうと思います。

※振り返る時間を作りたかったので、この記事では章立てからの執筆の一切までAIを使用していません。

2025年をふりかえる

1月 デザインスクールへ

この頃はデザインスクールに通っていました。 R&Dの機械学習エンジニアをしているとPoCの繰り返しで、実際に使われて役立つものを作りたい気持ちが募っていきました。 また、大学院卒業後5年ほどずーっと機械学習をやっており、「本当にこれでいいんだっけ？」という自分のモヤモヤを解消すべく、実際に使われている人の顔が見えるモノづくりとしてデザインを学んでみることに。 これがなかなか面白く、ツールの使い方などは苦戦しましたがゆるりと続けています。

また、デザインに直接関係することではないのですが、今までは「いいものを全部詰め込んだらいいものができるぞ！」という足し算的な思考になっていたのですが、デザインでそれをやるとゴチャついてしまい初心者らしい悪いデザインになるわけでして...。「いかに余計なものを削ぎ落として重要なものを際立たせるか」という 引き算的な思考 を取れるようになってきた気がします。デザインについては正直まだまだなのですが、普段とるメモやslackで打つテキストなどにはこの考え方が徐々に反映されてきており、ゴチャついていた頭の中もスッキリしてきた感覚があります。

2月 デザインスクール卒制

その卒業制作で通っている美容師のWebサイトを作ることになり、自然な縮毛矯正が得意とのことで一次情報を取りに自分の頭で体験しに行きました。 癖毛から自然な直毛に変わる感動体験ができて帰りの電車でサイト制作も捗りそうだなと思いながら帰路につきましたが、妻からはロン毛より前の方が良かったという一言がありました。まぁ、そういうこともあるよねと気にせずそのまま伸ばしています。

3月 SaaS企業へ転職 / 自分のコードが動いている

SaaS企業へ転職しました。 デザイナーやフロントエンドエンジニアのキャリアも悩みましたが給料の折り合いがつかず、PoCで終わらないSaaSの機械学習エンジニアとしてなら 作家性の発揮できるモノ作り ができるのではないかと捉えなおし続けてみることにしました。 初月に簡単なPull Requestをマージしてもらい、自分の書いたコードが裏側のデータ化エンジンの中で動いています。 作家性が発揮できてるかと言えばわかりませんが何かを残せているというなんだか不思議な感じです。

4月 商用コードの学び / パフォーマンス改善

前職の仕事内容的にPoCが多くシングルトンなど聞いたことすらなかったのですが、デザインパターンやクラス設計などコードベースを読み解きながらかなりのことが吸収できました。 またあまり詳しくは書けませんが、デプロイ環境下のコードのパフォーマンス評価を通してボトルネックの特定を行い、処理速度の改善を行いました。 実働するエンジンへのテコ入れはやってみたかったことなので、これらの経験だけでも転職してみて良かったなと思えました。 下の方に同僚の方に教えてもらって良かった書籍を載せてます。

5月 パフォーマンス改善してリリース

4月のパフォーマンス改善の延長で並列化による高速化を通して調整を行なったのちに、デグレ調査や負荷試験を経て無事リリースできました。嬉しい。

6月 プロプラエタリモデルの調査

この頃は既存エンジンとの比較調査としてプロプラエタリモデルの性能調査を行なっていました。いわゆるGPT4oやGeminiなどのことです。やはり特定ドメインにおいて画像と適当なプロンプトを入れるだけのデータ化は限界があり、データ化ルールをプロンプトとして与えることや画像と結果をfew-shotで与えるin context learningでどのように性能が変化するかを検証していきました。

7月 パッケージ管理ツール移行 / 正規表現メソッド整備

性能調査が落ち着いたので、poetryからuvへの移行や、新エンジンの日付項目で使う正規表現取得メソッドの整備などを行いました。日付表記は「令和oo年△△月」「2025年△△月xx日」「25年△△月〜△△月」など様々なので正規表現パターンも多く、それぞれのパターンにテストケースも複数あるためテストの整備が大変でした。

8月 発表で京都へ

プロプラエタリモデルの性能調査の内容を勉強会で話すことになり京都へ行くことに。学会にも同行することができトレンドを把握したりネットワーキングできたりと刺激になりました。

buildersbox.corp-sansan.com

9月 コードリーディング・技術調査 / 大阪万博旅行

この辺りから比較的大きめの調査〜機能改善を任されまして、コードベースのI/Fや一部設計を維持しつつ新機能を入れるにはどうしたら良いかと頭を悩ませました。苦戦の8割は既存処理の理解が要因です。おかげでコードリーディングを効率的に行うためのコツを掴めてきたのでその後のコード理解が捗り始めました。 その延長でチームメンバーのPull Request Reviewもより適切に行えるようになっていきました。 既存処理が理解できたら技術選定も行わなければなりません。要件をもとにパッケージや論文を調査し、「パッケージでできること」「処理速度」「ライセンス」などをまとめていきました。 Deep Researchを使って調査しましたが本当に便利。

プライベートでは日本で最後の万博開催となるかもしれないということで大阪万博へ。後半だったこともありいきたかったパビリオンはどこもものすごい行列でパビリオンに並ぶことすらできない状態だったので早々に切り上げました。一方で結婚記念日に背伸びして行ったミシュラン1つ星のフランス料理のレストラン、最高でした。いくきっかけはその頃見ていたグランメゾン東京の影響があるかもです。ここに行くためだけにまた大阪に行きたい、そう思ったので自分の中で3つ星をつけています。

guide.michelin.com

10月 技術選定の検証

技術選定の一貫で、複数パッケージの比較検証を進めていました。

11月 検証もTDDで丁寧に / 友人の結婚式

私の検証の仕方が良くなく、急がば回れ感があったので、ある程度大まかな要因が絞れてきたタイミングで確実にこれだという真因を特定することが重要だと感じました。また検証スクリプトであってもTDDを行うことで「検証結果が間違ってたので今までの方針で行なっていた実装を大幅変更する必要が出てきました。」といったリスクを回避できます。組み込み実装前の検証を思っている以上に丁寧にやることで最終的には検証を早く終えることにつながることを実感しました。

また、福岡の同じ幼稚園のときから中学・高専まで一緒で、今でも東京で度々会う友人の結婚式がありました。同じく彼も機械学習エンジニアで大学院の時にCVPRにアクセプトされてたりといつも刺激をもらっています。結婚式で印象的だったのは、料理学校にも通っている彼が料理のレシピを考え、それが結婚式のテーブルで振る舞われた料理の中でどれだったのかをクイズとして出してしまうという...またまた刺激をもらいました笑

12月 アドベントカレンダー参戦

前職では会社のテックブログやアドベントカレンダーを運営していたのですが、転職先でも何かしたいなと思いまずはアドベントカレンダーへ参加してみることに。Web・モバイル・ML・セキュリティなど垣根を超えて1つのカレンダーを埋めていく企業のアドカレ文化はいいですよね。クリスマスと並ぶ風物詩です。

buildersbox.corp-sansan.com

2026年はどうする？

テーマは「循環と俯瞰」

妻には厨二病みたいなテーマだねと言われましたがちゃんと意味があります。

循環

本番で動くコードを書けることが楽しく、1日の大半を 業務でのアウトプット に費やすことが増えました。それ自体は一見良さそうに思えますが次のような問題が起きてきました。

• 運動の時間を作れず脳の疲労が次の日に残るので2日間でみた アウトカム の総量はそこまで増えない
• 新しいインプットの時間を確保できず次の日も解決策の手札が増えておらず 同じ手札で考えるしかなくなる
• 新しいことをやることに気を取られすぎて 本番動作しているエンジンのミス改善が疎かになる
• 同じことをしているので 飽き が来て15時ごろから集中力が続かなくなってくる
• プライベート時間が疎かになり充実していても 自分の人生これでいいんだっけ？ と疑い始める

このように次の日に 成長するサイクル（循環） が作れていないことに気づきました。 そこで、次のことを始めました。

• 運動習慣のハードルを下げるため 朝起きたら散歩をして日光を浴びる （できたらランニング）
• 通勤時間中 feedly で技術記事をチェックし簡単なメモを添えてslackのtimes chなどに投稿 / 社内の論文読み会への参加
• 本番動作しているエンジンのミス要因を収集・分析 することで確実なミス改善を実施（チケットを切ってサブタスク化）
• 1日の中でメインタスクの間に 短時間で終わるサブタスク を挟んで飽きを防止する
• 自己分析を通して自身の 価値観・目標 を定義しその日の 行動がそこにアラインしているか を確認する

数ヶ月やってみた感じですが、朝の運動で覚醒して業務を始めるので集中力が増して業務効率があがっていると感じています。

また、 ミス分析と日々のインプットにより課題と解決策を紐付けられるように なり検証ネタが思いつきやすくなりました。社内外の勉強会や記事で出てくる技術用語の理解度も上がっているので話について行けるようになったのも嬉しい副作用です。

価値観・目標とのアラインはまだまだこれからですが、やること・やらないことを決める判断軸として機能しそうな予感はあります。ここは2026年でよりブラッシュアップしていきたいところです。

成長サイクル気づくきっかけになったのは社内でコーチングを受けていた堤さんのこの記事でした。とってもいい記事なのでぜひご覧になってください。

俯瞰

11月の検証時で大局的な視点と局所的な視点の2つの視点を持つことの重要性を痛感しました。 「検証を期間内に終わらせなければ...」「既存コードをベースにここだけ変えて一旦乗り切ろう」 といった焦りから局所的な視点に偏った見方をしてしまい、結果として設計レベルからやり直しが発生したりと回り回って非効率なやり方になってしまったなという反省があります。このことから脱力して一歩引いた客観的な視点で今やっていることを見直すことにしました。

客観的な視点は 他人に説明可能な視点 と考えるとわかりやすいでしょうか。「誰が考えてもこれが最適解だよね」というこの視点は、 作業にのめり込んでいる時ほど見失いがち です。他の選択肢があるのに今やっていることの延長にあると思ってしまっている。それをキャンセルするのも時には大事だなと思いました。

これは巨人の盗塁王だった鈴木尚広さんやyutoriの社長である片石貴展さんの発言に影響を受けました。（どこかの番組での発言でソースは出せないですが）

また、個人の認知について言う時は メタ認知 と言われていることが近いかなと思いますが、この視点は主観的なバイアスを排除した上で考えると「なんでこんな判断してしまったんだろう」といったことが多くあります。やはり人間ですので、自分の認知の歪みが判断に反映されがちです。 参考書籍では 大きな子供ブレーキ と言っているものがそれにあたります。適切な判断をしていく上では、これも俯瞰してキャンセルしていくことが重要なのでこの1年を通して意識的に取り組んでいきます。

ということで、「循環と俯瞰」について実践した結果を2026年の終わりに振り返ることができればなと思います。それでは！

参考書籍

実践 Python 3

新版　成長マインドセット 　心のブレーキの外し方