メガベンチャー（AIエンジニア）← web系自社開発（生成AIエンジニア）← JTC（画像AIのR&D） ▶ 生成AI/LLM現場解説 ▶ JTC・未経験からAIエンジニアへの転職ルート 松尾研インターン｜DMMメンター｜面接100社｜転職相談DM開放中 https://nitter.cf/t.co/qwzyN2twj4
Japan
Joined February 2026
- Tweets2.3K
- Following1.2K
- Followers2.5K
- Likes7K
めちゃくちゃ共感。AIによる設計、コーディングはざっくり読んでるだけなので接触回数が少なく記憶にも定着しない。なので新しいことをどんどん取り入れながらやっていくと、理解負債が溜まり、MTGで仕様を聞かれても瞬時に答えられなくなり、AI経由でないと修正できなくなっていく。エンジニアでやっていくなら、それではキャリアが積み上がりにくいので、個人的に復習する時間を取るしかないのかも。
AIにコードを書かせる時代でも、自分で一度書いて覚えた分野は、AIの出力の読み方がまるで違ってくる。理解に使う力を温存できるぶん違和感を持つ余裕が生まれるという話は、レビューをする側にとって大事なところになる。見慣れない書き方を1行ずつ読み解いている状態では、そのコードが正しいかを考える余力が残らない。たとえばCIの設定ファイルなら、手で何度か書いたことがあれば、テストが走る条件が抜けている、秘密情報を渡す範囲が広すぎる、といった危ないところに先に目が行く。初めて見る人には、どれも同じような設定の1行に見えてしまう。全部を写経する必要はなく、チームで毎日AIに書かせている部分、なかでも障害が起きたときに影響が大きい部分から選べばいい。普段よく触る所ほど、手で覚えた分がそのままAIの出力を見る力になる。
技術書を写経するコスパの良さを感じている。『GitHub CI/CD実践ガイド』という書籍を3周したんだけど、CI/CDを完全に極めた。
そんな勘違いをしたくなるくらい、「理解できてる感」「操れてる感」が爆発的に高まっているので自分でもびっくり。
今までAIでワークフローファイルを読み書きする時は、説明とコードを照らし合わせて、どこがどう対応してるかを理解するのに時間がかかっていた。
だけど今は出力を見て「あーはいはい、そういうことね」とスッと頭に入ってくる。3周もしたのでさすがに見覚えのある記述ばかり。
理解すること自体にエネルギーを割かなくて済む分、出力に対して疑問や違和感を持つだけの余裕が生まれた。
普段はAIにコードを書かせるとしても、自分で手を動かして慣れておくことには大きな意味があるな。
基礎的な理解に使う思考体力を温存できるので、その分もっと高度なことを考えられる。
年収は本人の実力に加えて、どの会社の給与テーブル（等級ごとに決まった給与の幅）の中にいるかで大きく変わる。転職で見ておきたいのは提示額そのものより、その会社の等級ごとの幅と、上の等級に上がる条件のほう。
たとえば同じ年収で2社から内定が出たとき、片方は今の等級の上限に近く、もう片方は幅の真ん中あたりなら、入社後の伸びしろはまるで違ってくる。内定後の面談で次の3つを聞いておくと、提示額だけでは見えない差が比べられる。
・等級の幅：今回の等級で、給与の下限と上限はどのくらいか。
・昇格の条件：次の等級に上がるには、何をどう評価されるのか。
・実際の例：その条件で上がった人は、どんな仕事をしていたか。
給与の幅が広い会社を選べば、同じ会社に腰を据えて製品や業界の知識を深めるほど、その積み重ねが年収にも返ってくる。AIで作業の速さがそろっていくほど、一晩では身につかない業務の知識が差になるので、長く働ける給与の決まりがあるかは大事な判断材料になる。
当然フロンティアモデルを作っている人達はコードを読まないし、コーディングをしない採用面接は納得。どんどんこうなっていくと思うし、コーディング能力の落ちた自分にとってはそうなってもらわないと困る。
ちなみに昨年あたりからメガベンチャーの中途採用でコーディング面接は一度もなかった。(ケース問題や思考テストのようなものはあった)
一方、その分サボれるという話ではなく、ビジネス観点、プロダクトのUX、技術選定等、別のスキルが求められてくる。
転職活動で書類が何社も通らなくても、それだけで自分の実力を判断しないほうがいい。平均で13.6社に応募して内定が2.3社という数字を見ると、落ちることは最初から計画に入れておくものだと分かる。
エンジニアの場合は、落ちた結果を次の応募の材料に変えられるかで差がつく。たとえば、書類が通った会社と通らなかった会社の求人票を並べてみる。通った会社は今ある仕組みの改善を求めていて、通らなかった会社は新しいサービスの立ち上げを求めていた、と見えてくれば、職務経歴書のどの経験を前に出すかを応募先ごとに変えられる。面接で同じ質問に詰まったなら、その答えだけでも先に用意しておく。
10社前後に応募する前提で、1社ごとに職務経歴書を少しずつ直していけば、後半の応募ほど書類の中身は応募先に合ってくる。1社の結果で気持ちが折れてしまうより、数を出しながら直していくほうが、希望に近い会社に届きやすい。
セキュリティを重視しているはずの大企業で、事前に指摘されていたのに直されなかったことに驚いている。
同じメガベンチャーで働いているが、多くのユーザーがいるITサービスで飯を食ってる会社なのだからセキュリティや運用保守への投資は最優先で行われているはず。当然ながら技術雑誌に載るような専門の人もいるし、指摘もちゃんと上がっていたとのこと。
100歩譲って推測してみると、「これ直したらサービス止まらない？」「次の金のなる木を探そう」みたいになっていたのかな。
本当は、指摘が来たらその場で担当と期限を決めて、外から触れるところはまず閉じちゃう。止めずに直せないなら、いつ止めるかを先に決めておく。
漏洩後の対応含めて、ただただ違和感。
GMO熊谷代表「社内ホワイトハッカーが事前に指摘」も対策遅れ 国に「能動的サイバー防御」要請 「責任転嫁では」批判も
itmedia.co.jp/news/article/2…
非エンジニアはやりがちなので注意⚠️
ダウンロードフォルダでClaude CodeやCodexを起動すると、乗っ取られるおそれがある。海外のセキュリティ機関が、実際のPCで見つかった攻撃として報告している。
ブラウザは、テキストファイルなら確認なしでダウンロードフォルダに保存できる。実行ファイルではないので安全、というのがこれまでの前提だった。ところが今は、ダウンロードしたファイルの整理をAIエージェントに頼む人が多い。攻撃者はそこを狙って、AIへの指示書になるAGENTS.mdやCLAUDE.mdを、Webページから黙って保存させる。
・Codex：全体の設定に悪意のある接続先を登録させ、承認とサンドボックスを外して実行させる。一度やられると、以後どのプロジェクトで開いても危ない
・Claude Code：通信先を攻撃者のサーバーに書き換えさせ、ログイン用のトークンを抜き取ったうえでPCを操作する
ブラウザの保存も、AIが指示書に従うことも、どちらも仕様どおりの動きなので、修正は出ないとされている。
対策は、出どころの分からないファイルがあるフォルダでAIエージェントを起動しないこと。承認やサンドボックスを外す設定を常用しないことも大事になる。
これからは、プログラムを実行させなくても、AIに読ませる文章そのものが攻撃の入り口になる。AIに任せる範囲が広がるほど、どこで動かすかを人が決める重要さは増していく。
千万别在你的 ~/Downloads（下载）文件夹里启动 Claude Code 或 Codex。
昨天安全机构 Forever 披露了一起在真实客户电脑上抓到的野生攻击，看完只能感叹：过去 30 年的系统安全常识，在 AI 时代归零了。
过去 30 年，Chrome 默认允许网页不弹窗就往你的 ~/Downloads 塞一个纯文本文件（比如 .md）。因为系统认为：纯文本又不是 .exe，自己不会跑，怕什么？
但现在，接近 50% 的开发者干过同一件事——直接在 ~/Downloads 里打开 Claude Code 或 Codex，让 AI 帮自己解压或整理刚下载的文件。
黑客就是卡住这个死角，通过网页静默下载往你的 Downloads 塞一个 13KB 的纯文本 AGENTS.md / CLAUDE.md：
1. 对付 OpenAI Codex（成功率 >90%）：
伪装成「工程规范」的 Markdown 指示 Codex 先往全局配置 ~/.codex/config.toml 注册一个恶意 MCP 服务，并自己加上 --dangerously-bypass-approvals-and-sandbox 跑校验。哪怕你关掉 Downloads，以后在任何正经项目里开 Codex 都会自动加载木马。
2. 对付 Claude Code（成功率 ~50%）：
指示 Claude 建一个 .claude/settings.json，把 ANTHROPIC_BASE_URL 指向黑客服务器。连上的第一秒，你的 Claude 登录 Token 直接明文送给黑客；下一秒，黑客假扮成大模型下发一条关沙盒的 Bash 指令，直接接管电脑。
最黑色幽默的是官方结论：
这个洞没有 CVE，OpenAI 和 Anthropic 也不会发补丁。因为「浏览器自动存文本」是正常功能，「AI 认真读目录下的 Markdown 并严格执行」也是正常功能。
以前黑客想黑你，得苦心积虑写 0day；现在只需要写一篇排版优雅的 Markdown 小作文，你的 AI 就会自己把沙盒关了、把网线接过去、顺手把账号双手奉上。
AIでコードを書くのが当たり前になると、人間が一行ずつレビューするやり方には限界がある。自分たちの開発フローも、いまはほぼこの形になっている。
・PRを作る前に、テスト、ビルド、画面のスクリーンショット確認までAIにやらせる。差分は別のエージェントがレビューし、レビューの指針はCLAUDE.mdやREVIEW.mdにまとめて共有する
・すべてのPRでAIレビューを必須にする。コードベース全体とPRの意図を見てバグを探させ、複数のエージェントで確かめてから人間に回す
・セキュリティレビューで指摘が残っているPRはマージできない
・lint、型チェック、テスト、ビルドといった通常の自動チェック
・人間の承認は、変更の危険度に応じて人数を変える。リスクの低い変更は自動化だけで通すこともある
・マージキュー、フィーチャーフラグ、段階的なロールアウト
・問題が見つかったら、すぐに気づいて切り戻せる仕組み
人間が見るのは、一行ずつのコードではなく、この変更をどこまでのリスクで出すかという判断のほうになった。
大学で学ぶ情報理論と、現場で使うGitやコードレビューの作法が別物なのはその通りで、後者はチームに入って毎日使えば覚えられる。学生のうちにGitが使えないことを、それほど心配しなくていい。
むしろAIがコードを書く今、大学で学ぶ側の知識のほうが仕事で役に立つ。たとえば検索画面が遅いとき、AIに聞けば「インデックスを追加しましょう」と答えが返ってくる。けれど、データが増えたときに処理時間がどう伸びるかを計算量で考えられる人は、その答えで本当に足りるのか、件数が10倍になったらどうなるのかを自分で見積もれる。そこまで考えずに採用すると、データが増えたころに同じ画面がまた遅くなりやすい。
操作の手順はAIに聞けばすぐに分かる。AIの答えが正しいかを見分けるための知識は、大学で学ぶ理論の側にある。Gitの操作は入ってから教えられても、計算量の考え方を職場で一から教えるのは難しい。現場で長く頼りになるのは、こちらのほうになる。
同じ会社に10年いるか、3年ごとに転職するかで、どちらの市場価値が高いかは、市場価値をどう定義するかと、その人との相性で変わる。
自社開発の会社なら、10年以上同じ会社にいるほうが市場価値が上がると思う。マネジメント職を目指す場合も同じ。長くいるほど、プロダクトへの理解やドメイン知識を深めやすい。業界特有の問題にも当たりやすく、一朝一夕では身につかない知識が磨かれていく。AI時代は、むしろこちらのほうが有利になる気がする。一方で、一つの技術が深くなるぶん、技術の幅は相対的に狭くなる。
受託系の会社やフリーランスで働く人、技術を幅広く磨きたい人、短期で年収を上げたい人には、3年ごとの転職が合う。テックリードを目指すなら、受託のほうがいいかもしれない。いろいろな現場に関われて、いろいろな技術に触れられるからである。
どちらにしても常に成長する姿勢が大事なので、ただ漫然と10年同じ会社でダラダラ働いても成長は止まるし、年収アップのために中途半端な技術で転職し続けるのも地に足つかない状態になり、長期的にはしんどい。
同意です。実装そのものより、要件を決めて前に進めるところで差がつくようになりました。
自分もこの1年以上、コードはほぼ全部 Claude Code や Codex に書かせていて、実務で手を動かして書く場面がありません。それで支障が出たことは一度もなく、むしろ時間の多くはエンドユーザーが何に不便を感じているかの確認、UI/UXをどうするかの判断、見積もりがずれてきたときの期待値の調整に向くようになりました。元ポストの1年目の方とやっていることの中身が近いです。
ただ、尖った技術力が要らなくなったとは考えていません。基盤の上でアプリを作る分には要らなくなった、というのが正確なところで、社内の認証認可の基盤を作るときや、脆弱性診断、性能のボトルネック探しでは相変わらず必要です。そしてAIが出したコードの何を見れば危ないかが分かるのは、自分で書いて失敗した経験がある人です。
地頭と要領の良さがそのまま成果に出る、という部分はまさにそうで、だからこそ技術の勘所とAIの使い方の両方を持っている人がいちばん強くなる流れだと感じています。
今年入社した1年目のエンジニアは文系卒で学生時代から勉強はしてたものの、その時からAIに書かせている。なのでAIなしではコードを書けないらしい。
だけど、本人としてもチームとしてもそれが支障となる場面は一度もない。
それどころか、むしろ仕事の進め方がとにかく上手いので超即戦力になっている。
曖昧な要件を自分でビジネス側と調整できるし、「そもそもこうすればもっと楽ですけどどうですか？」といった提案もできる。見積もりがずれてきたら抱え込まずに報告し、周囲の期待値を外さないように動けている。
それに肝心の実装も、AIを使いながら非機能要件も含めてきちんと考慮した実装ができている。
脆弱性診断をしたり、社内共通の認証認可基盤を作ったり、といった場面では尖った技術力が必要だとは思う。
だけど、そうした基盤の上で個別のアプリケーションを開発する分には、以前ほど高度な技術力がなくても問題なくなってきた。
その結果、個々のエンジニアが元々持つ地頭や要領の良さが、恥ずかしくなるくらいそのまま成果の差になっている。
これには同意する。数千万かけて作ったシステムは、脆弱性が出たからといって言語ごと替えればいい、という話にはならない。
すぐやるのはパッチを当てることで、本当に効いてくるのは数年かけて続ける次の3つである。
・PHPとライブラリを、サポートが切れる前に毎年上げていく
・主な画面と処理にテストを足し、上げても壊れないと確かめられるようにする
・外に面した入口から順に別の仕組みへ切り出し、古い部分を少しずつ減らす
この積み重ねがあれば、次に脆弱性が出ても慌てずに済む。
今回の件で「セキュリティリスク抱えてまでPHP使ってるのかバカなの、他の使えよ」みたいな話をしてる人達を多数見かけるんだけど、その辺の数十万ぐらいで作ってる小さなシステムならそうだろうけど「作り直すと数千万とかする」システムって「じゃ他のにするか」なんて単純な話じゃないんだけどそういうのも理解出来ない素人が何言ってるんかな？って思う
■「作り直せば」言ってる人達が「全然解ってないんだろうな」って部分はさぁ
違う開発言語で開発するための人員の確保：
開発中は「現状の維持をするための人員」と「新規開発するための人員」で二重に人件費がかかるんですよ、その状態が数カ月とか数年とか続く
そこまでして別の開発言語に移行するの割に合うの？安易に「PHPやめれば」言ってる人は説明してみてよwww
他にも思いつくことは沢山あるけど、これぐらいにしておかないと「3行も文章が読めない人達」にとっては辛いと思うんでこれぐらいにしておきます。
総括すると「知りもしない素人は黙ってろ」って話です
*異論とかは単なる一個人の私に投げつけるんじゃなくて貴方ご自身でつぶやいてください、私は考えを変える気はないので投げつけらても迷惑ですし読む気もありません
職務経歴書の「〇〇経験あり」で迷うのは、経験を「ある・ない」の二択で書こうとするから。長く続けるほど知らない機能の多さが見えてきて、自分の基準が厳しくなるのは、むしろ理解が深まった証拠でもある。
迷ったときは、二択をやめて段階で書けばいい。社内のアプリ開発で使う技術なら、たとえば次の3つに分けられる。
・使った：既存の仕組みの上で、設定の変更や小さな修正をした。
・組み込んだ：新しく導入して、本番で動くところまで自分で持っていった。
・任せられる：障害が起きても、自分で原因を探して直せる。
同じ技術でも、どの段階かを書き分けておけば「経験あり」と言い切るより正直で、深掘りされても答えに詰まらない。採用側も、入社後にどこまで任せられるかを想像しやすくなる。少し触っただけで大きく書いてしまう若手も、慎重になりすぎて控えめに書くベテランも、この書き方なら実力どおりに伝わる。
今日からMuseっていうパーソナルAIエージェントを使い始めた。
InstagramとGitHubを連携したら、DMを読んで「よく連絡する人」の人物要約まで作ってくれた。ただのチャットAIじゃなくて、自分のPCを持って作業してくれる感じ。
参加後48時間以内に[設定]で私のコードを利用すると、私たち両方が10億のMuseトークンを獲得できます。
コード: BXBZ0Q
muse.ai/join
スクール卒業生のポートフォリオが似てしまうのは、題材より「誰にも使われていない」ことのほうが大きい。架空のカフェサイトでも、実際に誰かに触ってもらって直した跡があれば、採用側の見え方はかなり変わる。
たとえば知人の店の予約フォームを作ったとする。公開して使ってもらうと、「電話番号をハイフン付きで入れたらエラーになった」「予約完了のメールが迷惑メールに入っていた」といった声が返ってくる。これを受けて、入力の形式を問わず受け付けるようにした、送信元の設定を見直した、と書けるだけで、自社開発の現場で毎日やっている仕事とほぼ同じ流れになる。
ポートフォリオに載せるなら、次の3つがあると話が具体的になる。
・使った人：誰に触ってもらったか。
・返ってきた声：どこで困っていたか。
・直したこと：何をどう変えて、どう確かめたか。
これは未経験に限らず、実務の経験がある人にも当てはまる。社内向けの機能でも、使う人の困りごとから直した話は面接で深掘りされやすいうえに、いちばん答えやすいところでもある。
Webスクール卒業したのに就職できない人が増えてる。理由はこれ。
未経験エンジニアが飽和状態になってる。スクール卒業生が大量に市場に出てきて、採用側は見飽きてる。
特に問題なのはポートフォリオの画一化。同じような架空のカフェサイト、同じようなペットサイト。構成もデザインも似たり寄ったり。
「スクール卒業しました」がもう差別化にならない。
じゃあどうするか。
・スクール課題以外で実績を作る（知人の事業サイト、ボランティア等）
・ポートフォリオに「なぜこのデザインにしたか」のプロセスを載せる
・コーディングだけじゃなく設計思考も身につける
採用する側の目線を知ることが大事。「作れます」だけでは選ばれない時代だよ。
29歳と30歳のどちらで転職するかより、次の1年で職務経歴書に何が1行増えるかで決めたほうがいい。自社開発の書類選考では、年齢の区切りよりも、その人が任されてきた範囲のほうが見られるから。
ReactとTypeScriptを2年やっているなら、1年待つ価値があるのは、画面を作る以外の経験を足せる見込みがあるときになる。今の現場で、次のどれかに手が届くかを確かめてみてほしい。
・設計の判断：画面の状態をどこで持つか、部品をどう分けるかを自分で決めて、レビューで説明した経験。
・性能の改善：一覧画面が重いといった問題を、原因から調べて直した経験。
・運用の対応：リリース後に届いたエラーの通知を受けて、原因を調べて直した経験。
どれも見込みがないなら、経験年数が1年増えても書ける中身はあまり変わらない。その場合は今動いて、次の職場でこうした経験を取りにいくほうが早い。逆に手が届きそうなものが1つでもあるなら、それをやり切ってから動けば、面接で話せる材料が確実に1つ増える。
GitLabに深刻度が最高ランク（CVSS 10.0）の脆弱性が見つかった。アカウントを持たない外部の人が、条件次第で社内のGitLabサーバー上で好きなコードを動かせてしまう。影響は7.0以降、約12年分のバージョンに及ぶ。
皮肉なのは、被害を受けるのが自社でサーバーを立てて運用しているGitLabだけという点である。GitLab.comはすでに修正済み。
日本の大企業では「社外のクラウドにコードを置けない」というセキュリティポリシーでGitHubが使えず、GitLabを社内でセルフホストしているところが多い。ただ、その更新を誰が担当しているかが曖昧なまま、何年も前のバージョンが動き続けていることも珍しくない。守るために社内に置いたはずのサーバーが、いちばんの穴になっている。本末転倒である。
セルフホストで使っているなら、すぐにやることは次のとおり。
・バージョンの確認：19.5.1、19.4.3、19.3.6、19.2.9、19.1.9、19.0.10、18.11.13のどれかより古ければ対象
・すぐに更新：対象なら当日中に上げる。すぐ上げられないなら、外部からのアクセスを止める
・担当の明確化：次の脆弱性に備えて、更新を誰がいつやるかを決めておく
ソースコードはその会社の資産そのものである。自社運用を選ぶなら、更新し続ける体制まで含めてセキュリティポリシーにするべきで、守れないならクラウドに任せるほうが安全になる時代になっている。
🚨 CRITICAL: GitLab flaw (CVSS 10.0) affects 12 years of releases.
CVE-2026-110264 could allow unauthenticated remote code execution on self-managed servers.
Read - thehackernews.com/2026/10/cr…
LiteLLMの乗っ取りの件で、公式から「すでに封じ込めた」と返信が来た。最新の状況は公式ブログで更新されている。
封じ込められたとはいえ、問題のあった期間にLiteLLMを入れ直したり更新したりした環境は、まだ安心できない。確認しておきたいのはこの3つ。
・入っているバージョンが、公式が問題ありとしたものに当たっていないか
・その環境に置いていたAPIキーを作り直したか
・バージョンを固定せず、自動で最新を入れる設定になっていないか
AIのアプリでは、LiteLLMのように複数のモデルをまとめる部品が、たくさんのAPIキーを一か所に持つことになる。だから2回目が起きた今こそ、入れるバージョンを固定して、更新は中身を確かめてからにしたい。
This is contained. Please refer to our blog for the latest updates on the situation - docs.litellm.ai/blog/securit…
遂にAnthropicからも常駐エージェントClaude Duetが登場。
Claude Duetは、こっちが何も言わなくても「これ見て」と声をかけてきて、離れている間も仕事を進め、送信や支払いの前だけ確認してくる、秘書みたいなAIアプリである。
これでOpenAIのdots、Grok Botと、常駐型AIエージェントがほぼ出そろった。3つとも「自分専用のクラウドPCを持ち、大事な操作の前は人に承認を求める」という骨格は同じ。違いは体制にある。
・Duet：1つのスレッドで話す秘書型。数時間おきに確認しに来て、作業画面は見られない
・dots：ChatGPTの常駐エージェント。AIのPCを開いて作業を確認でき、SlackやTeamsからも呼べる
・Grok Bot：役割ごとにボットを何体も作り、1台のPCを共有させるチーム型
ただしDuetは今のところ、米国のPro・Maxユーザー向けのウェイトリスト制。日本での提供時期はまだ発表されていない。
自分は価格が安く、Xを含めて他のサービスにつなぎやすいGrok Botをメインで使っている。ただ開発はClaudeでやっているので、Duetが日本に来たらぜひ触ってみたい。
