はじめに こんにちは。カイポケコネクトの開発推進チームでエンジニアをしている @_kimuson です。 普段は生産性向上のための基盤構築などをフロントエンド領域中心に行っています。 弊社では中途入社が中心だった状況から新卒採用にトライしており、私自身も新卒の面接に出たり、インターンの学生を受け入れ、一緒に開発を進めたりといった機会がありました。 彼らの考えを聞いたり、インターン生の相談に乗ったりする中で感じたのが、生成AIが当たり前に存在する時代にキャリアを始めるエンジニアは、以前とは異なる難しさに直面しているということです。これは誰か個人の資質やふるまいの話ではなく、環境が変わったことで構造的に生まれやすくなっている傾向の話で、程度の差こそあれ我々既存のエンジニアにも同じことが起きていると思っています。 エンジニア本人も勿論、受け入れる側の難しさも非常に高くなっていると感じており、この問題について考えてみようと思います。 生成AI時代に、キャリア初期の学習が難しくなる理由 生成AIはエンジニアの生産性を大きく向上させてくれる一方、エンジニアの学習機会を奪いやすいツールでもあると思っています 一般にもよく言われている話もあるかなと思いつつ、構造を整理してみようと思います この記事では便宜上、新しくエンジニアとしてのキャリアを開始する人のことを「新人」と表記します。 質問するまでの摩擦が、思考を訓練していた 以前は、分からないことや困ったことがあった際には人間のメンターに質問をするという前提がありました。 メンターという人間の時間を借りて質問をすることになるので、メンター側からの要望あるいはメンティー側の気遣いの両輪から「調べてわかることは自分で調べ、わからないところはどこがわからないか整理して質問する」という引力が自然に発生していたと思います。組織によっては悩んでいることをIssue Up出来ずにずっと悩んでしまう問題を解消したいこととセットで、「15分ルール」などをルールとして敷くケースもあったと思います。 そしてこの質問のための準備段階で自然と 何を実現したいのか 現在は何が起きているのか 期待していた結果は何か どの時点から予想と異なったのか すでに何を試したのか 自分は何を分かっていないのか といった点を言葉にして整理をします。結果として物事を構造化して整理する・理解するという能力を育てていた側面があったと思っています。 実際、質問内容をまとめていたら情報が整理できて答えが分かってしまった！という話はよく聞きますし、私も経験があります。 ところが現代は生成AIという「手間を取らせること」をまったく気遣わなくて良い専属のメンターが登場しました。 相談がカジュアルにできてかつ人の時間も取らないということで良い面ももちろんありますが 時間を取らせること 質問の仕方（調べればわかるじゃん？とか結局なにが聞きたいの？とか） といったことに一切気を使わなくて良い相談相手ができてしまったことになります。論点が曖昧なまま質問してもAIがよしなに補ってくれますし、前提や知識が不足していれば調査して補完してくれます。 結果、（もちろん個々人の使い方に差異はありますが）、新人から「質問前に自分で調べる・調べた情報を整理/言語化する」というプロセスが奪われやすくなっています。 こういった物事の構造化・言語化・整理といったスキルは、エンジニアリングで課題を解決していくための根幹となる重要な能力だと思っていますが、これを培う場が1つ失われてしまっていると考えられます。 「分かった気にさせてしまう」AIが狂わすメタ認知 問題を自分で整理しなくても回答へ到達できることには、もう1つ学習に関する難しさがあります。 生成AIは、わからないことに対して「答え」を教えてしまうだけでなく、利用者に「分かった気にさせる」ことが本当に上手です。 適切に情報を取捨選択して分かりやすく整理して並べてくれる 言葉の意味や、論理の繋がりで分からなかったところがあれば気兼ねなく聞くことができ、自分に最適化された補足を提示してくれる 具体例や比較表、場合によってはVisual化して説明をしてもらえる 一方、LLMの説明と質疑を通して分かった気になっている状態と、実際に使える（正しさを適切に判断したり、注意すべき観点を見つけられる）状態とでは乖離があります。 自分がすでに「できている」と思っている対象を改めて調べたり、手を動かして解像度を高める必要性は感じづらいでしょう。 にも関わらずアウトプット・成果は出ていくので「能力が適切に拡張されていること」と「成果が出ていること」が乖離しやすいと感じます。 AI に任せて良い範囲を見つけることの難しさ 生成AIを使うことで学習機会を奪われるのであれば、素朴に対策を考えると生成AIの利用を適切に制限するのが良いという発想になります。 単純作業は生成AIを使いたいとして、「自分がイチからやってできないことは学習を目的に生成Agentの利用を制限する」が一見良さそうに思えます。 しかし問題は、何を生成AIへ任せて/なにを自力でやるべきなのかを、本人が判断しなければならないことです。 1つの開発タスクには、複数の工程があります。 チケットや要求を理解する 既存の仕様とコードを調べる 問題を分解する 実装方針を決める コードを書く 動作を確認する 問題があればデバッグする レビューを受けて修正する こういった工程を包括的にAgentに任せている場合、先ほど説明した「分かった気にさせてくれるAI」の特性と相まってどの工程はできていて、どの工程はできていないのかをきちんと認知することが難しいでしょう。 つまり「AIに任せて良い範囲」を決めるには、その前提として自分の現在地を正確に把握できている必要があります。ところが前述のとおり、その現在地の把握こそが生成AIによって最も狂わされやすく、非常に厄介です。 学習機会の喪失にどう向き合うか ここまでAgent活用による弊害として学習機会の減少があるという話を構造的に整理してきました。 単純にコードを書く機会が減る（かつその経験も少ない）という要素に加えて 気を使わない相談役が言語化能力の成長機会を奪う 学習のために重要な「できていないこと」のメタ認知が狂わされやすい という要素を説明しました。 ここからはこれらを踏まえつつ、私も明確な答えは持っていないのですがどうやって受け入れをしてくのが良いのかを考えてみようと思います 生産性と学習機会はトレードオフであることを認識する まずちゃんと認識すべき重要な要素として「生産性と学習機会はトレードオフである」ということがあると思います t-wadaさんの有名なスライド、「質とスピード」では、メンバーの成長や学習機会がスピードとのトレードオフになっているのではないか、ということが示唆されています 生成AIは色々な目的で利用できますが、特にエンジニアリングの現場でこれだけ活用が進められているのは既存のエンジニアのコーディング業務を移譲して生産性をかなり高められるということが最も大きいと思います。 一方、速度（生産性）が学習機会とトレードオフになるのであれば、生成AIをゴリゴリ使って生産性をN倍にしよう！という営みの裏には学習機会の喪失がセットになっているとも考えられます。 もちろん定型的でその業務からもう学習することはほぼない工程というのは存在し、そのエンジニアの経験値やAIへ移譲する業務に応じて失っている学習機会の大小は明確にあると思います。そして特に新人の場合は様々な工程、それこそ開発ツールの調査1つとっても学びになる要素が多分に含まれており、非常に多くの学習機会が失われやすいのだと思います。 生成AI登場以後で、「自分ができないことはできない」という当たり前の前提が崩れ、自分ができないこともそれっぽいアウトプットが出せるようになった結果、このトレードオフ関係がより明確になったと感じています。 「生産性を上げる」というのは一般にポジティブに捉えられると思いますが、学習とのトレードオフであり、「学習をしたいなら生産性を敢えて捨てる」ということを文化として受容していくことも大事になるのではないかなと思います。 新人の教育では特にそうですし、既存のエンジニアでも新しい技術領域へのチャレンジや、職能を跨ぐ（Ex. プロダクト方向・デザイン、 ...etc）チャレンジにおいても同じことが言えると思います。 生産性をあげるためではなく、学習を支援するための AI活用 ここまでの話から結論を出すと、生成AIを使う=気づかないうちに学習機会を奪われるかつ、どこで奪われているかの判断も難しいので学習期間では一律で生成AI自体を禁止する、ということになります。 これ自体は一定ワークすると思いますし、実際弊チームでもこういった課題感がレトロスペクティブで共有され、実際に一定期間生成AIを禁止するといったことも試しています。 実際にこの取り組みをしていたインターン生の佐藤さんが、AI禁止で開発に取り組んだ半年間について記事を書いています。受け入れる側ではなくインターン生側の視点で書かれているので、こちらも読んでいただけると嬉しいです。 とはいえ、せっかく生成AIという便利なツールがあるのに一律禁止して単純作業もすべて自分で行い、原始的な学習プロセスを使うのもベターではあるがベストではないんだろうなと思っており、「生産性をあげることではなく学習を支援すること」を目的に生成AIやAgentを活用できると良いのではないかなと思っています。 grilling skill 学習を支援するAIの利用方法として、私が開発の計画段階でよく利用しているgrillingというスキルのアプローチが教育と相性が良いと感じているので紹介させてください。 grillingはおもにAgentを使った開発における「実装計画を立てる」フェーズで利用されるスキルです。 種々のAgentツールに組み込まれているPlan Modeの親戚だと思ってください。 両者の違いですが、Plan ModeはAgentが立てた実装計画を人間が承認する構造なのに対して、grillingではAgentがInterviewerになり、人間側が考えている実装方針などとの共通理解が得られるまで質問を繰り返す構造になっています。 私がgrillingを気に入っているのは、計画を立てることの主体を生成AIから人間側に取り戻した点です。 結局計画で大事なのは「自分が求めているものをいかに齟齬無くAIに伝えるか」なので、私の中ではこの形がベストだなと思っています。 そしてこの「主体を人間側に取り戻す」grillingのアプローチが学習に目的を置いたAI利用にもかなり効くんじゃないかなと思っています。 grillingの場合は主体が人間側になるので、AIが提示したそれっぽい方針をなんとなくの理解で進めることができません。「こういうことをやりたい」と伝えた後に タスクのスコープはどこからどこまでですか？別の箇所にも影響しますよね、そこはどうしますか？ やり方としてA/B/Cがありますよね、どの方針でやりますか？ Aで実施する場合、α が問題になりますよね。これはどうやって対策しますか？ といったように様々な方向から、曖昧になっている箇所をAgentから質疑されます。これにちゃんと自分で考えて答えるようにしていくと 様々な観点が曖昧なまま成果物だけが出てくることを避けられる 判断自体の是非は置いておいて、Agentから提示された自分の中になかった観点においてもすべて自分で判断をしていくことになる 成功したらそれで良いですし、特に失敗（人間のReviewプロセスで棄却される、Releaseしてみてから問題に気づく）をしたときにも、自己判断をしたうえでのフィードバックになるので学びに繋がりやすい という良い学習サイクルを効果的に回しやすいのではないかなと思っています。 Coaching をする AGENTS.md / Skill を用意する grilling自体はあくまで認識を齟齬無く伝えるためのスキルで教育にも活きやすいと思うものの、教育用途に最適化されているわけではありません。例えば意思決定自体は委ねられますが想定回答を出すように指示されているので、教育目的なら想定回答もない方が良いのでは？といった具合です。 なので、この辺りのアプローチを参考に教育のために指向性を絞るための指示をAgentに与えると良いかなと思っています。 あくまで一例ですが例えばAGENTS.mdや専用のスキルに 利用者は学習フェーズであり、作業を請け負うのではなく利用者へのコーチングに徹すること 答えやその示唆になる提案を禁止し、代わりにInterviewを行うことで、利用者の能力拡張を阻害せずに学習を支援する 利用者が発見できていない論点の提示を行うことで学習を支援するが、その論点において「どうすべきか」は提示しない 学習機会にならない単純作業（=工程が複雑でなく、言語化されていない判断を必要とするプロセスも存在しないほど明確）は、本質的な内容に時間を使うため請け負ってSubagentに実行させて良い。ただし、この単純作業かの判断は利用者ではなくAgentが判断に責任を持つ ※ ここの判断基準については受け入れ側がある程度言語化しておけるとなお良い といった内容を記載しておき、Agentの動きを制限した上で利用してもらうことで 生成AIによる学習機会の喪失を最小限にする 生成AIによる学習の支援を行い効果的に能力拡張を行う 単純作業は、Agent側の判断により一部実施することで非効率な時間は最小化する というようなことができるのではないかなと思っています。 上記の例はあくまで1案でしかないので、むしろAI Nativeな世代の側からこういった問題点を解消した良いアプローチが出てくると良いなと思ったりしています 終わりに 生成AI時代にキャリアを始めるエンジニアの学習の難しさと、それを受けてどういう風にエンジニア側/受け入れ側が学習をしていけると良いのかについて考えてみました。 正直結論や成果が出ていると言うより課題感の共有がメインで、こういうアプローチもあるんだなくらいで受け取ってもらえると幸いです。願わくば世間的にもこういった生成AI時代を前提にした受け入れのプラクティスについて固まってくると嬉しいなと思っています。 また、今回は主に新卒だったり新しくキャリアを開始するエンジニアをスコープに書きました。ただ、こういった話はわれわれ既存のエンジニアの写し鏡でもあると思っていて、より影響が大きいのは彼らというだけで、同じ問題を持っているんだと思っています。自分にできないことを移譲しているつもりはなくても暗黙的にそういう要素はあり、学習が阻害されている側面は少なからずありそこに向き合っていく必要があるんだろうなと感じています。 生産性を追い求めた結果、課題を解くエンジニアリングの能力自体が衰えてしまっては本末転倒なので 学ぶことのない（少ない）状態になっている作業をAgentに寄せていって速度を高める・他の時間に当てやすくする 学ぶことの多い・それ自体がトレーニングになる課題解決の本質に集中する・割く時間を増やす この2軸のバランスを両立させながら、Agentと付き合っていけると良いなと思っています。

はじめに 2026年8月21日から2026年8月22日にかけて開催された PyCon JP 2026 に参加しました。 2026.pycon.jp 弊社からはバックエンドエンジニアの陶山 嶺が登壇しました。また、今年は弊社 RevComm もゴールドスポンサーとして PyCon JP 2026 に協賛いたしました。 今回はイベントの振り返りを紹介します。 登壇振り返り 詳解ASGIミドルウェア　シンプルながらも奥が深いASGIミドルウェアを使いこなす 概要: Pythonで本格的なWebアプリケーションを開発するためには、ASGIに対する理解は極めて重要です。本セッションではそのASGIのしくみの全てが詰まっていると言っても過言ではないASGIミドルウェアに焦点を当てて紹介します。アイディア次第で用途が広がるASGIミドルウェアのしくみを理解し、使いこなしていきましょう。 登壇者: 陶山 嶺 登壇の感想 PyCon JPでの登壇はこれまでにも何度かありますが、それでもやはり直前はスポンサーブースにいる同僚たちから「今日ずっとソワソワしていますね」と言われるくらい緊張していました笑 発表自体は直前まで何度も練習していたこともあり、全体的に上手く進めることができてよかったです。登壇後には「知らない話も聞けてすごく面白かったです」と言っていただけて発表して良かったなと改めて感じました。 今回の自分の発表時間帯は2日目午後だったので、次回があればパーティよりも前に発表できたら嬉しいです！笑 ブース運営について 今年はスポンサーとしてブースを出展させていただきました。 ブースまでお越しいただいた皆様、大変ありがとうございました。 PyCon JP 2026 RevComm ブース ブースには弊社で開発・提供している MiiTel の特徴を視覚的に理解いただけるよう、動画とパネルを展示しました。 また、ちょうど PyCon JP 2026 開催直前の2026年8月13日に、登壇者の陶山 嶺が執筆した「Python Web開発実践入門 ―― FastAPIによるWeb API開発と非同期処理」が発売されたため、ブースにも展示しました。FastAPI や Python による Web アプリケーション開発にご興味がありましたら、ぜひご覧ください！ gihyo.jp 印象に残ったセッション Python and language learning: How did Python help me get the JLPT N1 英語を母語とする学生として来日し、やがて日本語のエンジニアリングチームを率いながら JLPT N1 に合格するまでの 10 年間の歩みについてのJose 氏のトークです。海外出身のエンジニアが日本で働くうえで日本語力の重要性が高まっている昨今のビザ要件もあり、このセッションは非常にタイムリーで意義深いものに感じました。 特に印象的だったのは、Jose 氏が自身の言語学習の経験を、ソフトウェアエンジニアとしての専門性と直接結びつけていた点です。一般的な教科書や単調な暗記に頼るのではなく、Python や最新の LLM を活用することで、自分に最適化された学習ツールを作れることを示してくれました。以前は学習素材を集めるために Web スクレイパーを書いて、ニュースサイトなどからデータを収集していたそうですが、現在では LLM を使うことで、そのようなコンテンツをその場で生成できるようになっています。 また、フラッシュカード作成のための genanki や、発音分析のための onsei といったオープンソースライブラリを活用し、自分の弱点に合わせたパーソナルな学習環境を、まさにプログラムによって構築していた点も印象的でした。この話を通じて、プログラミングのスキルを使って、新しい言語を学ぶという複雑なプロセスを「ハック」できるのだと視点が変わりました。紹介された具体的な方法にとどまらず、Python を活用すれば、さまざまな言語学習の目標に対して、もっと創造的なアプローチができるのではないかと感じました。  2026.pycon.jp Retry Is Not a Strategy: Classifying and Recovering from AI Agent Failures in Python LLM エージェントを開発していると、原因が分かりにくいサイレントな失敗や、意図しないループへの対処に悩まされることがあります。Cyrus Mante 氏のトークは、まさにそのような課題に正面から向き合う内容でした。単に最初からリトライして「今度はうまくいくはず」と期待するのではなく、Cyrus 氏は triage というオープンソースライブラリを紹介していました。 このライブラリを使うことで、開発者はエージェントの実行ステップを分析し、失敗の原因を具体的に特定できます。たとえば、誤ったツールを呼び出したのか、ループに陥っていたのか、外部 API で問題が発生したのか、といった切り分けが可能になります。 さらに優れていると感じたのは、復旧方法の扱いです。発生したエラーの種類に応じて、システムがエージェントの状態をロールバックするのか、再計画を強制するのか、あるいは人間にエスカレーションするのかを自動的に判断します。また、このようなルーティングロジックを肥大化した LLM プロンプトに任せるのではなく、Python のコードとして明確に保つという考え方にも強く共感しました。堅牢な AI システムを構築するうえで非常に実践的なアプローチであり、自分たちのエージェントにもぜひ取り入れて試してみたいと感じました。  2026.pycon.jp Pyxelで、プログラミングを遊ぼう！ Pyxel の作者である北尾崇氏 ( https://github.com/kitao ) による 2 日目の基調講演です。 github.com 本質的な価値を追求するためにライブラリに意図的に制約を加えている、という点はライブラリの開発だけでなくプロダクト開発においても重要な視点なのではないかと感じました。その他にも、Pyxel v3 の構想や AI 時代における活用や意義など、興味深い内容がたくさんありました。 Pyxel は今まで使ったことがなかったのですが、今回の発表を聞いてぜひ遊んでみたいと思いました。 おわりに 筆者は PyCon JP に参加したのは今回が初めてのことでしたが、想像以上に参加者やセッション数が多く、非常に熱気を感じるイベントでした。セッションや基調講演にも興味深いテーマの発表が多く、素晴らしいイベントであったと感じています。 RevComm において Tech イベントでの本格的なブース運営は初めてという状況ではありましたが、ブースまで足を運んでいただいてありがとうございました。 お知らせ 2026年9月9日 (水) 19:00〜20:30 にSanSan株式会社様・株式会社ニーリー様・弊社の共同で PyCon JP 2026 の非公式アフターイベントを開催いたします！オンラインで開催いたしますため、ぜひお気軽にご参加ください！ sansan.connpass.com

はじめに デジタルテクノロジー戦略本部 AI戦略室のT.Sです。 2026年7月、オーストラリア・メルボルンで開催されたSIGIR 2026（49th International ACM SIGIR Conference on Research and Development in Information Retrieval）とICTIR 2026（ACM Conference on Innovative Concepts and Theories in Information Retrieval）に参加してきました。学生時代に取り組んでいた研究の成果をICTIRで発表するとともに、SIGIRでは世界中の研究者や企業が発表する最新の研究に触れることができました。 今回の記事では、現地の雰囲気や印象に残った研究、そして実際に参加して感じたことを紹介します。 SIGIRとは？ SIGIRは、情報検索（Information Retrieval: IR）分野を代表する国際会議の一つです。 検索エンジンやレコメンドシステム、RAG、LLMを用いた検索技術など、私たちが日常的に利用している情報サービスを支える最先端の研究成果が発表されます。 2026年はオーストラリア・メルボルンで開催され、会場には世界各国から多くの参加者が集まりました。会場には大学の研究者だけではなく、企業研究者も数多く参加しており、アカデミアと産業界が密接につながっていることを実感しました。 印象に残った発表 今回聴講した発表の中で、特に印象に残ったのがLinkedInによる Policy-Grounded Dynamic Facet Suggestions for Job Search という発表です。 求人検索では、「Data Scientist」や「Software Engineer」のような短い検索クエリが多く、検索キーワードだけからユーザーの本当の意図を理解することは簡単ではありません。 例えば、「AIエンジニア」という検索でも、 新卒なのか 経験者なのか 勤務地はどこなのか どの技術領域を求めているのか によって、ユーザーが求める求人は大きく異なります。 この発表では、検索ランキングモデルを改善するだけではなく、ユーザー自身が検索意図を具体化できる仕組みを導入していました。具体的には、検索窓の下にユーザーの特徴や入力した検索クエリに応じた動的なファセット（検索条件候補）を表示します。ユーザーが提示された条件を選択すると、その情報が検索条件へ追加され、より明確な検索意図で求人を探せるようになります。 私が特に興味深いと感じた点は、「検索システムがユーザーの意図を一方的に推測する」のではなく、「ユーザーとのインタラクションを通じて検索意図を明確化する」という考え方です。検索技術というとランキングモデルや検索アルゴリズムに注目しがちですが、良い検索体験を実現するためには、ユーザーがどのように情報を探すのかまで含めて設計することが重要だと感じました。求人サービスにおいては、ユーザーと企業のより良いマッチングを実現することが重要です。その観点でも、このような検索意図を引き出す仕組みは非常に参考になる取り組みだと感じました。 ICTIRでポスター発表 SIGIR開催後には、併催国際会議であるICTIRにも参加しました。私は、学生時代に取り組んだモデルマージを情報検索分野に応用する研究について、ポスター発表を行いました。 本研究では、各ドメイン向けに個別に学習したDense Retrieverをモデルマージによって統合することで、複数ドメインに対応可能な単一のDense Retrieverを構築できるか検証しました。 発表では、 モデルマージの有効性 Mixture of Expertsとの違い ドメイン数を増やした場合の性能変化 などについて議論を行いました。 自分の研究内容を英語で説明し、質問やコメントをいただきながら議論できたことはとても良い経験になりました。 メルボルンの街並み 学会期間中にはメルボルン市内も少し散策しました。 街中には歴史ある建築物と近代的な高層ビルが共存しており、とても魅力的な都市でした。 参加して感じたこと 今回で海外での研究発表は2回目でした。日本生まれ日本育ちの私にとって、英語で自分の研究内容を伝え、海外の研究者と議論することは決して簡単なことではありませんでした。それでも、自分の研究についてさまざまな視点から意見をいただいたり、世界中の研究者による最新の研究成果を直接聞いたりできたことは、非常に貴重な経験となりました。 またSIGIRでは、検索とLLMの融合がさらに加速していることを強く感じました。今回は、Deep Researchに関連する研究をはじめ、検索技術にAgentやReasoningを取り入れた研究が数多く発表されていました。情報検索の分野も新たな技術が登場するたびに形を変えていることを実感しました。 おわりに SIGIR・ICTIRへの参加は学生時代に取り組んだ研究の発表が主な目的でしたが、企業に勤めるデータサイエンティストとしても大きな学びになりました。世界中の研究者が取り組む課題や最新技術を直接知ることで、自分自身の視野が大きく広がったと感じています。今回得た知見を今後の業務に活かしながら、引き続き検索・推薦・生成AI分野の技術をキャッチアップしていきたいと思います。 最後までお読みいただき、ありがとうございました。