いた｜HR Tech CTO

HR Tech スタートアップCTO
← PM, PO, テックリード, ブリッジエンジニア, 電気通信大学大学院中途退学, 電気通信大学卒

技術の深掘りをはじめ学ぶことが大好きです。にんにくも好きです。
開発や技術関係のご相談、雑談お気軽に承ります。
気になる方はDMかリプへどうぞ！

[いた｜HR Tech CTO @it__garlic]

知らない概念についてはAIに質問できない、というのが地味に盲点だと思う。

AIって聞かれたことには答えてくれるけど、聞かれてないことは黙ってる。Observabilityを知らない人が「Webシステム作って」と頼んだら、動くものは出てくる。でもそこにObservabilityの提案が含まれるかは完全に運任せで、大抵は含まれない。

これって要するに、AIの出力の上限はプロンプトを書く人間の認知範囲に縛られるということで、自分の知識の外側にあるものには手が届かない構造になってる。

怖いのは、知らないこと自体に気づけないところ。動いてるから大丈夫だと思ってしまう。実際には観測できてないだけで、障害の種は静かに育ってたりする。

AI時代に本当に価値が上がったのは「正解を出す力」じゃなくて「正しい問いを立てられる力」の方なんだろうな。問いの質がそのまま成果物の質になる世界が、もう来てる。

[徳永広夢 @tokuhirom]

例えば､素人が動くウェブシステムを作れたとして､Observability が確保出来てるかって話｡Observability のことを知らない人が AI を使っても Observability は一生確保されない｡

[axa@marketing @axis_arcs]

曖昧なところをハルシネーションで埋めてもらったら��局質が上がらなかったので、
レビューAgent2段階9視点にしたら安定した…気がする。

[いた｜HR Tech CTO @it__garlic]

スキーマ定義あるある

APIの入力、DBのカラム、フォームのバリデーション、レスポンスのDTO。最初は1つにまとめようとして、結局境界ごとに別物になっていく。

無理に共通化したスキーマが「ここだけoptional」「ここだけnullable」で穴だらけになるあれ、毎回経験する。境界ごとに別スキーマで持つ方が、最終的に読みやすくなることが多いと感じてる。モノレポか分割かをツールの好みで決める話、見るたびに違和感がある。

コンウェイの法則の言うとおり、コードの構造は組織の通信構造を反射する。チームが頻繁に同期するならモノレポがハマるし、独立に動くならポリレポの方が摩擦が少ない。逆向きで強行すると、ツールが正しくても組織側で摩耗する。

技術選定として議論する前に、自分たちの通信頻度がどうなっているかを観察した方が、答えに近づきやすいと思ってる。

[いた｜HR Tech CTO @it__garlic]

AIコーディングあるある

実装を先に頼むと「それっぽいけど微妙に違う」コードが返ってきて、レビューに時間が溶ける。

先にテストを書いて「これを通せ」と渡すと、出力が一気にまともになる体感がある。AIは曖昧な仕様を曖昧なまま埋めてくる。テストは仕様の言語化を先に強制する装置として、ちょうど噛み合うと感じてる。

[いた｜HR Tech CTO @it__garlic]

エージェント運用あるある

プロジェクト全体のルールも、特定タスクの指示も、全部1枚のCLAUDE.mdに詰め込んで、後でどこに何を書いたか分からなくなる。

Claude Codeは作業ディレクトリから親方向にCLAUDE.mdを階層的に読み込む。どの階層に何を置いたかが、そのまま読み込み順とコンテキスト消費を決める。共通はルート、ワークフロー固有はそのディレクトリ、と切り分ける設計が、ファイル整理ではなく実行モデルに直結してる。

[いた｜HR Tech CTO @it__garlic]

CLAUDE.mdを充実させたら逆に出力が荒くなった、という経験が何度かある。

最初は親切心で「これも書いておこう��「あれも知っておいてほしい」を積んでいくと、コンテキストの先頭が肥大化する。重要なルールが他の情報に埋もれて、結果として指示の遵守率が落ちる。

何を書くかより、何を書かないかを決める方が難しい。情報量と精度がトレードオフになる構造を意識してから、CLAUDE.mdは半分くらいに���った方が動くようになった。

[いた｜HR Tech CTO @it__garlic]

副業の損得を時給単価だけで計算するの、見落としが多すぎると思ってる。

例えば月20時間、時給5,000円の副業なら月10万円。ここから引かれるのは税金だけじゃない。本業の集中力、休日のリカバリ時間、新しいドメインの学習時間、コンテキストスイッチによる本業の生産性低下。これらを差し引くと、実質的な手取りは見かけの半分以下になる感覚がある。

「単価×時間」で見えるのは収入の上限で、コストは別軸で積み上がっていく。両方並べないと判断を誤る。

[いた｜HR Tech CTO @it__garlic]

リポ構成を決める時、最初に見てるのは「チーム間のSlackチャンネル数」と「週次の同期会議の数」だ。

3チームが同期会議週2回、横断PRが月10件以上なら、モノレポにした方がCIや依存解決の摩擦が消える。逆にチーム間でほぼ会話がなく、独立リリースが基本なら、分割した方がデプロイ判断のスピードが上がる。

結局のところ、組織のコミュニケーション帯域がツール選定の入力データになってる。技術論の前に組織観察が要る話だと感じてる。

[日本ライフログ研究所│両瀬真和（Lifelog Laboratory） @Lifeloglab]

この視点重要で、自分のログで人格AI作った時もまさに起きた。
ただ自己ログの場合に怖かったのは、
AIより「自分の記憶」の方が普通に補完してたこと。
設計だけでは解釈の揺れは消えなかった

[いた｜HR Tech CTO @it__garlic]

「全部Docker化すれば本番と一致する」と信じて全部突っ込んだ環境、結果的に遅くなる経験が何度かある。

Mac上でDocker Desktopを介すとファイルシステムのIOが体感で数倍遅い。ホットリロードが鈍る、テスト実行が伸びる、��動だけで数十秒。1日に何十回も繰り返すと、無視できない時間になる。

本番一致の安心感と、開発中の往復速度はトレードオフだ。全部Docker化が常に正解じゃなくて、何をDockerに置き、何をホストに残すかの境界設計の話だと感じてる。

[いた｜HR Tech CTO @it__garlic]

AIが自信たっぷりに間違える原因を「ハルシネーション」で片付けるの、もったいないと思ってる。

実際の現場で発生してるのは、コンテキスト不足のまま回答を要求された時に、最も尤もらしい補完が出てく��構造的な現象だ。モデル側の欠陥というより、入力設計の欠陥として見た方が打ち手が増える。

「分からない」と言える前提条件をプロンプトとコンテキスト両方で揃えないと、何度モデルを変えても同じ間違え方をする。問題はモデルじゃなく設計の側にあると感じてる。

[いた｜HR Tech CTO @it__garlic]

短命プロトタイプと5年運用するサービスで、Prismaの評価が真逆に振れる経験を何度かしてる。

立ち上げ1〜2ヶ月、テーブル20以下くらいの規模なら、Prismaの開発速度はかなり効く。一方でテーブル100超え、複雑なJOINやレポーティングが入ってくると、生成SQLの読めなさと負荷の予測しにくさで詰まる場面が増える。

ORMを「永遠の正解」として選ばずに、寿命と規模を仮置きしてから選ぶ方が、後で剥がす時のコストが下がる。盲信もアンチも保留する余地を持たせたい。

[いた｜HR Tech CTO @it__garlic]

DROP COLUMNやDROP TABLEを「あとで掃除すればいい」で��く設計、自分は怖くて取れない。

不可逆操作はロールバックの選択肢を消す。本番で問題が出た時、戻すという最終手段が使えなくなる。ALTERで一段階置く、データを別カラムに移してから消す、こういう面倒な分割の方が結果的に安全だ。

「とりあえず動く」より「いつでも戻れる」を優先したい。マイグレーションの良し悪しは、書いた時より戻したくなった時に分かると思ってる。

[いた｜HR Tech CTO @it__garlic]

「TDDは時間がかかる」と言われてきたけど、AI生成を併用する開発では逆になる感覚がある。

実装を先に出させると、レビューと修正に2〜3往復かかる。テストを先に固めてから実装させると、初回でほぼ通る。トータルの時間は明らかに後者の方が短い。

人間が手で書いてた頃は��テストを書く時間がそのまま実装の時間に上乗せされていた。AIが実装側を圧縮できる現状では、TDDの「先に仕様を固める」工程が、ボトルネックの直撃に効くようになった。手段の評価は前提が変われば変わると感じてる。

[いた｜HR Tech CTO @it__garlic]

マルチエージェントあるある

並列化したら速くなる、と思って3エージェント同時に走らせたら、出力��マージする段階で前提が食い違って、結局統合に時間を溶かす。

並列化で得てるのは実行時間で、失ってるのは前提の一貫性なんだと思う。マージのコストが見えてないと、トータルでは直列より遅いことが普通にある。並列度は速さじゃなく、統合可能性で決めたい。

[いた｜HR Tech CTO @it__garlic]

Server Components普及でTanstack Queryいらなくなる、みたいな話をたまに見るけど、自分の実感とは違う。

初回描画はRSCに寄せた方が速いのは確かだ。ただクライアント側の楽観更新・��限スクロール・ポーリング・キャッシュ無効化までRSCで賄うのはまだ無理がある。

役割の重なりじゃなく、棲み分けが見えてきた段階だと思ってる。RSCが「届ける」、Tanstack Queryが「触る」。両方使う前提で設計した方が結果的に薄く済む。

[いた｜HR Tech CTO @it__garlic]

技術記事あるある

書き始めたら自分の理解が浅いことに気づいて、調べ直して、結局書き終わった頃には最初に書きたかったことと別物になってる。

このプロセスこそが本体で、書いた記事は副産物に近いと感じてる。逆に「書きたいことが最初から最後まで変わらない記事」は、書く前に理解が完成してたか、表層をなぞっただけかのどっちかになる。

[いた｜HR Tech CTO @it__garlic]

「なんとなく動いてるからいいや」で次に進んだ理解は、半年後に必ず利息付きで請求が来る。

ライブラリの内部挙動を雰囲気で使���てる箇所、CIの設定で意味の分からない呪文、これらは積もると「触るのが怖いコード」を作る。1回30分の調査を惜しんだ結果、半年後に1日溶かす規模の問題に化けた経験が何度かある。

放置のコストは時間軸で見ると指数で効いてくる。表層理解で進む癖は、長期で見るとスキルの天井を作ると感じてる。

[いた｜HR Tech CTO @it__garlic]

エージェント設計で「自己検証ステップ」を1つ挟むだけで、出力の信頼性が体感で大きく変わる。

直接回答するフローと、回答→根拠を再確認→確信度が低ければ「不明」と返す、を分けたフロー。同じモデル・同じプロンプトでも、後者の方が誤答率が明らかに下がる。

精度を上げるためにモデルを変えるより、検証フローを設計に組み込む方が安いし効く。AIに「分からない」と言わせる設計は、モデル選定よりもパイプラインの設計の���だと感じてる。

[いた｜HR Tech CTO @it__garlic]

PGとテックリードとPdM、3つの視座を行き来した経験で、同じ事象の見え方が別物になることが何度もある。

PGからは「この実装がきつい」、テックリード視点では「全体への波及がきつい」、PdM視点では「リリース時期に対する影響がきつい」。同じ「きつい」が、判断レイヤーで意味する内容が変わる。

1つのレイヤーに留まると、自分が見えて��ない別レイヤーのコストを体重に乗せて判断してしまう。視座の行き来は意思決定の解像度を上げるための実体験的な訓練だと感じてる。

[いた｜HR Tech CTO @it__garlic]

AI活用あるある

「これ確認して」と曖昧に投げて、それっぽい答えが返ってきて、後で間違いに気づくあれ。

確認の基準・参照すべきソース・分からない場合の振る舞いをプロンプトに含めると、出力が「確信を持った推測」から「根拠付きの判断」に変わる体感がある。AIに分からないと言わせるには、分か��ない時の振る舞いを先に渡す必要があるんだと思ってる。