本ブログは、 株式会社テイツー 様とアマゾン ウェブ サービス ジャパン合同会社が共同で執筆いたしました。 AWS 上に既にあるリソースを別のシステムの一部として活用しよう、というアイデアを思いつくことは頻繁にあるかと思います。しかし実現に向けたアクションとなると、連携方式の選定や既存システムへの影響評価など検討すべきことが山積し断念、気がつくと巨大で複雑な連携システムが出来上がっていた･･･こんな経験はありませんか。テイツーはこの課題をクラウドの特徴を捉えたシンプルな設計判断で乗り越え、わずか約 3 ヶ月での新サービスリリースを実現しました。 このブログでは既存の AWS 資産を活用した新サービス創出までのアプローチと、リユース業界における店舗 DX の取り組みについてご紹介します。 株式会社テイツー（以下、テイツー）は、「古本市場」「ふるいち」「トレカパーク」などのリユース店舗を全国 180店舗（執筆時点）展開する東証スタンダード上場企業です。同社はトレーディングカードの読取査定機「 TAYS 」の開発・運用を通じて、 AWS の活用を進めてきました。テイツーはこの TAYS の AWS 基盤を活かし、店舗向け POP 自動生成サービス「POP×THREE」をわずか約 3 ヶ月で開発・リリースしました。 リユース業界における店舗運営の課題 テイツーは 1989 年の創業以来、書籍、家庭用テレビゲーム、トレーディングカード、ホビー、スマートフォン、CD、DVD、衣類など幅広いカテゴリのリユース品を取り扱い、「家族で楽しめる廉価な娯楽の提供」を事業の柱としてきました。近年はトレーディングカード市場の拡大に伴い、トレカ読取査定機「TAYS」を自社開発し、BtoB サービスとして外販するなど、テクノロジーを活用した事業展開にも積極的に取り組んでいます。 一方で、リユース業界特有の課題として、商品の買い取り価格が市場動向に応じて日々変動するという点があります。特にトレーディングカードの分野では、新タイトルの発売や大会の開催などによって価格が大きく変動するため、店舗に掲示する買い取り告知 POP を頻繁に更新する必要があります。 これまでは全店舗に配信する買い取り告知 POP の作成に、1 回あたり約 1〜2 時間の作業時間を要していました。主な作業内容はカードの価格変更やタイトルの入れ替えですが、告知を一から作成する場合にはさらに多くの時間がかかるケースもありました。全国の店舗に対してタイムリーに情報を届けるためには、この POP 作成業務の効率化が不可欠でした。 TAYS から POP×THREE へ – 既存 AWS 基盤を活かした新サービス構想 テイツーが運用するトレカ査定システム「TAYS」は、読み取りスキャナーと連携し AWS を中心としたクラウド上でAIによる判定、データ閲覧と編集を可能にした、トレカ買い取りに特化した基盤です。 TAYS の基盤では、Amazon Aurora MySQL を DB サーバとして採用し、Amazon EC2 上のLinux でアプリケーションを稼働させています。AWS WAFによるセキュリティ対策も施されており、全国の店舗からインターネット経由で安全にアクセスできる構成となっています。 TAYS 自身は元々、外販向けの構想や個店ごとの価格設定などを見据えて設計されていました。つまり、そのデータベースには買い取り以外にも店舗運営に必要な商品・価格情報が蓄積されており、新たなサービスを構築するためのデータ資産がすでに存在していたのです。 ここから生まれたのが「POP×THREE」です。TAYS のデータ資産とインフラ基盤を API 経由で活用し、その上にフロントエンドを構築するというアプローチで新サービスを開発できるのでは、という発想からスタートしました。実装内容をなるべく少なく、リリースを速くしたいという方針のもと、2025 年 9 月下旬に開発をスタートし、同年末には提供を開始しています。 POP×THREE のサービス概要 POP×THREE は、TAYS に蓄積された商品・価格データを活用し、店舗向けの買い取り告知 POP を効率的に作成するサービスです。商品データを一括投入し、テンプレートを活用して POP を量産するツールとして設計されています。画像認識には独自構築の画像認識モデルを用いており、カード画像の細かな違いを認識することでトレーディングカードにおけるバリアントの判定も可能となっています。 システムアーキテクチャ POP×THREE はあくまでフロントエンドとして機能し、バックエンドは既存の TAYS 基盤との連携を前提に設計されています。ここでは、TAYS の既存基盤と POP×THREE の新規構成の両方をご紹介します。 TAYS + POP×THREE 基盤 TAYS POP×THREE 構成図（一部省略） TAYS のシステム基盤は、以下の構成となっています。 ネットワーク・アクセス: Amazon Route 53 による DNS 管理、 Elastic Load Balancing (ALB) によるトラフィック分散 コンピューティング: オートスケール構成のAmazon EC2 データベース: Amazon Aurora MySQL をメインの DB サーバとして採用 ストレージ連携:カード画像・スキャン画像・OCR ログなどのデータを各サーバ間で共有。画像処理や一括データ更新を実行 セキュリティ: AWS WAF による Web アプリケーション保護 POP×THREE のワークロード増加に伴いオートスケール化とセキュリティ強化策を講じることで、TAYS は全国の店舗と本部を結ぶより堅牢なシステム基盤として安定稼働しています。 POP×THREE の構成 POP×THREE は、TAYS の資産を最大限に活かすことを念頭に、既存 AWSアカウントに同居する形で構築しました。東京リージョンの 2 つのアベイラビリティゾーンにまたがる構成で、高可用性を確保しています。 ネットワーク・アクセス:共通 ALB によるトラフィック分散 コンピューティング: Private Subnet 内に本番環境・検証環境で分離して配置 キャッシュ: Amazon ElastiCache を本番・検証それぞれに配置し、パフォーマンスを最適化。スロークエリログおよびエンジンログを CloudWatch Logs で管理 セキュリティ: WAF Charmと共通 AWS WAF による Web アプリケーション保護 ログ管理: Amazon CloudWatch Logs と Amazon Data Firehose によるログの収集・S3 への転送（本番・検証それぞれ）。AWS WAF ログ、ALB ログも Amazon S3 に保管 設定管理: AWS Systems Manager パラメータストアによる構成情報の一元管理 設計上のポイント POP×THREE の設計において最も重要な判断は、TAYS の既存データをどのように新サービスから利用するかという連携方式の選定でした。新システムを構築する際の一般的なアプローチとしては、①DB レプリカや DMS によるデータ同期、②既存システム側に専用 API を公開し新システムがそれを利用する、③既存 DB を直接参照する、といった選択肢が考えられます。 テイツーが採用したのは②のアプローチです。TAYS 側に POP×THREE 専用（連携アプリ用）の API を設置し、POP×THREE はその API を介して商品・価格データを取得する構成としました。この判断の背景には、TAYS と POP×THREE で保守を担当する開発ベンダーが異なるという事情もありました。①のレプリカ構成では DB 構造への依存が強くなり、スキーマ変更のたびに両ベンダー間で調整が発生します。DMS によるデータ同期についても、レプリケーションの複雑性と継続的なメンテナンス負荷を踏まえ、現在の運用体制では現実的ではないと判断しました。③は②の構成が取れれば必要ありません。 API を採用した最大の狙いは、システム間の責務を明確に分離し、将来的な変更や機能追加のスピードを確保することにあります。これを介することで、DB 構造変更時の影響範囲は TAYS 側に閉じ、POP×THREE 側は API の後方互換性さえ保たれていれば独立して開発・デプロイが可能です。保守ベンダーが異なっていても、調整コストを最小限に抑えながら利用者の要望に迅速に応えられる構成となっています。一方で、POP×THREE から見れば TAYS が稼働していなければデータ取得ができないという依存は残りますが、Aurora MySQL 自体の高可用性構成と、読み取りレプリカの追加による柔軟なスケーリングにより、実運用上のリスクは許容範囲と判断しました。 加えて年内リリースの方針のもと、各ベンダーがスケジュール遵守を前提に開発を進める必要がありました。API のインターフェース仕様を早期に確定させたことで、TAYS 側（API 公開）と POP×THREE 側（フロントエンド構築）の開発を並行して進められたことも、約 3 ヶ月という短期間でのリリースを支えた要因です。AWS という共通のクラウド基盤上で IAM やネットワーク設計が標準化されていたことで、異なるベンダー間の技術的な齟齬が生じにくかった点も大きく寄与しています。 導入効果 POP×THREEにより、テイツーでは以下の効果が得られています。 業務効率化 すでに POP×THREE を導入している外販先企業では、数時間単位での業務効率化につながっているとのことです。 テイツー直営店での本格利用はこれからですが、全店舗に配信する予定の買い取り告知 POP の作成業務において、運用次第では 1 枚あたり約 30 分程度の作業時間短縮が見込まれています。従来は 1 回あたり約 1〜2 時間を要していた作業であり、特に価格変更やタイトルの入れ替えといった定型的な更新作業での効率化が期待されます。 外販先での実績を踏まえ、さらなる効果が期待されています。 安定稼働とスケーラビリティ POP×THREE はサービス開始以来システムダウンを経験していません。テイツーは「クラウドの恩恵として、マネージドサービスでインフラ管理コストを下げつつも、安定稼働している」と評価しています。 スケーラビリティの面では、直近でトレーディングカードのビッグタイトルが発売され大規模な負荷が発生した際、TAYS のオートスケール対応を実施しました。常時複数台のサーバを配置する構成へ移行し、今後のさらなるトラフィック増加にも対応できる体制を整えています。 AWS の活用メリット テイツーが AWS を活用する中で特に評価しているのは、以下の点です。  複数ベンダーとの円滑な連携: POP×THREE の開発では複数の開発ベンダーに依頼しましたが、AWS という認知度の高い基盤があったことでスムーズに連携を行うことができました 適切なサービス選択の提案: AWS からの技術支援により、要件に合った適切なサービスの選択を行うことができました クラウドの安定性: お客様向けサービスの基盤として、高い可用性と安定稼働を実現しています テイツー様からのコメント 「当社として本件は単なるシステム導入事例ではなく、AWS ならではのスピーディーな立ち上げとして対外的に発信できるテーマだと考えています。 トレカ査定システム TAYS の開発・運用を通じて培った AWS 基盤を最大限に活用することで、POP×THREE を約 3 ヶ月という短期間で立ち上げることができました。既存の RDS を活用し、フロントエンドの開発に集中するというアプローチは、実装をなるべく速く、少なくしたいという当社の方針に合致するものでした。また、AWS からの適切なサービス選択の提案により、限られたリソースの中でも最適なアーキテクチャを構築できたと感じています。 本取り組みは、既存データ資産を活用し小さく始めることで再現可能なモデルであり、AWS の各サービスの機能を利用して継続的に最適化できる点も大きな強みです。 システムの安定稼働はお客様へのサービス品質に直結するものであり、クラウドの恩恵を日々実感しています。今後も AWS の技術を活用し、リユース業界における店舗 DX をさらに推進してまいります。」 — 株式会社テイツー 情報システム部マネジャー 野口 義弘 様 今後の展望 テイツーでは、POP×THREE の展開をさらに加速させるとともに、AWS 基盤の強化を進めていく計画です。現在は TAYS が公開する API を介したデータ連携により運用していますが、導入先の拡大に伴うトラフィック増加に備え、Aurora の読み取りレプリカ追加やキャッシュ戦略の見直しも視野に入れています。さらに、中長期的には API の拡充やイベント駆動型の連携導入により、TAYS と POP×THREE それぞれが独立してスケール・進化できるアーキテクチャへの発展を段階的に進める方針です。直営店についてはこれから POP×THREE の利用を本格化させる段階であり、現場からのフィードバックを得ることで今後の展開を検討していく予定です。 テイツーの取り組みは、既存の AWS 基盤を活かして新たなサービスを迅速に立ち上げるという、クラウド活用の好例です。リユース業界における店舗 DX の推進に向けて、テイツーの挑戦は続きます。

本記事は、下記イベントに対するセッションレポートとなります。 イベント名：Regional Scrum Gathering Tokyo 2026 日時：2026/01/07 登壇者：Kei Ogane 氏 セッション名：複雑さを受け入れるか、拒むか？事業成長とともに育ったモノリスを前に私が考えたこと 本記事の筆者は、モバイルアプリ開発エンジニア、アジャイル開発のスクラムマスター、という立場で案件支援業務に主に携わっています。最近は、生成AIを活用した開発プロセスの整備・導入の支援業務も担当しています。このような立場で感じたセッションレポートを、下記に共有いたします。 セッション内

はじめに：AIに 取って代わられる 恐怖よりも、エンジニアとして学ぶべきことの多さに恐怖している 4月で、エンジニアとして4年目に突入しました。まだまだ、エンジニアとして未熟だと痛感する毎日でございます。私は、プロダクト開発に関わる傍ら、AIを組織に導入したりその後の活用を推進するプロジェクトにも属していました。 プロジェクトの進行で必要な知識をつけるために、AIモデルプロバイダーが発信する知識や、LT会・カンファレンス・社外の事例の記事を調べています。その中で感じているのは、エンジニアとして学ぶべきことの多さです。AIについて調査すればするほど、取って代わられる恐怖よりも、「これからエンジニアとしてこんなに学ばないといけないのか…？」と学ぶべきことの多さに戦慄しています。 2026年4月22日（水）に Sansan株式会社Eight主催のテックリードカンファレンス に参加しました。本記事では、そこで感じたことを、それを増強するための書籍・動画で発信されている知識と組み合わせてお伝えしようと思います。 左: 和田 卓人氏(タワーズ・クエスト株式会社　取締役社長)　右: 佐藤 治夫氏(株式会社ビープラウド　代表取締役社長) なお、本記事は 4ヶ月前に書いた記事(AI時代も変わらない、ソフトウェア開発の基礎) の続きという位置付けでもあります。基礎の重要性を改めて確認し、より具体的な「ではどうするか」に踏み込んでいく内容です。 TL;DR（この記事のまとめ） 「AIに取って代わられる恐怖」や「AI爆速開発の焦り」への対応は、分からないことを放置せず基礎をコツコツ学び続けること。 AIは「簡単さ（Easy）」を極限まで高めたが、システムを「シンプル（Simple）」にしてはくれない。複雑性を切り分け制御できるのは、ドメインや技術を深く理解している人間の役割である。 「1人でAIと爆速開発」というリソース効率の罠から抜け出し、モブプログラミングや Agent Skills による「チームでの意思決定と暗黙知の言語化」へ向かう。 AIエージェントとの関わり方：物的生産性から離れ、対象物を深く理解する カンファレンスでハッとさせられたのは、和田卓人氏の「 AIによる物的生産性に血眼になっているのではないか？ 」という問いかけでした。 AIによってコードの記述スピードは劇的に上がりましたが、だからこそ「誰もいらないものを高速に作っても意味がない」状態になっています。和田氏は講演の中で、AIの登場によってプロトタイプを用いた価値の検証が容易になり、「 価値探索とプログラミングがかなり紐づいてきた 」と語っていました。コードを速く書くことではなく、対象物を深く理解し「何を作るか」を探索することに、エンジニアの主眼は移りつつあります。 この「 スピード（簡単さ）に溺れず、理解を優先する 」という姿勢の重要性は、世界的なソフトウェアエンジニアリングの潮流とも完全に一致しています。Netflix のエンジニア Jake Nations 氏による講演「 The Infinite Software Crisis 」では、次のように指摘されていました。 簡単（Easy）はシンプル（Simple）を意味しない。簡単とはシステムに素早く追加できることであり、シンプルとは自分のやった仕事を理解できることだ。簡単を選ぶたびに、私たちは「今のスピード」と引き換えに「後々の複雑さ」を選んでいる。AIは簡単さを極限まで高めたが、シンプルさを生み出すわけではない。 何を作るかを理解し設計することの難しさは、どのツールも排除できません。 また、「 Software Fundamentals Matter More Than Ever 」という講演でも、次のように語られていました。 「コードは安い」という言説は誤りである。悪いコードは今まで以上にコストが高い。変更しにくいコードベースは AI の恩恵を受けられない。 これは私が4ヶ月前に書いた記事でも触れた DORA レポートの「AI は増幅機」という主張と重なります。良いコードベースであるほど恩恵を受けやすく、悪いコードベースであるほど機能不全が拡大する。基礎の重要性は、AI 登場後にむしろ高まっています。 この点について、『ソフトウェアエンジニアガイドブック』（Gergely Orosz 著）の日本語版特別付録インタビュー（p.557）でも、次のように語られていました。 「問題は、経験の少ないエンジニアがAIに『主導権を握らせ』、AIが何をしているのか理解しないまま仕事を全部任せてみたくなるように誘惑されることです。したがって、『AIと共に学び続け、思考をAIに外注しないエンジニア』への需要は増加するものの、その供給はおそらく減少します！奇妙な時代が訪れることでしょう」 理解を放棄してAIに主導権を渡さない姿勢こそが、これからのエンジニアの価値を左右しそうです。 では、AIに主導権を渡さず、自分たちの理解を保ちながら開発するにはどうすればいいのか？  その具体的な対策として和田氏が推奨していたのが、 Test First でやる場所と、Red-Green-Refactor のように小さなサイクルで回す場所を分ける  ことでした。 エージェントに任せても良いと判断した領域では、ざっくりとした Test First で問題ない。一方で、人間がリアルタイムにレビューして品質を担保したい領域では、Diff（差分）の小さい TDD のステップを強制する方がよい。これは、人間が何千行ものファイルを一気にレビューして理解するのは現実的ではないからです。 AIの爆速な出力に流されず、人間の認知負荷を意図的に下げるために、理解できる範囲に留める仕組みとして、非常に納得感がありました。 開発速度の見直し：モブプログラミングの再評価とリソース効率の罠 AIの登場により、コーディング工程は劇的に短縮されたように感じる場面が多くなったのではないでしょうか。しかし、Tech Lead Conference 2026 でのSansan株式会社（笹川裕人氏）のセッションでも指摘されていたように、開発プロセス全体のボトルネックは「コーディング」から「レビューやテスト」へと移動しています。 かつてGitHubが普及した頃、「1人1ブランチで開発できる＝リソース効率100%」という発想が、プルリクのレビュー待ちというボトルネックを生みました。今、「コーディングエージェントをN列並列で動かす」という発想も、全く同じパターンにはまる危険性があります。 真のボトルネックは、コードを書くことではなく、人間側の判断・レビュー能力です 。 この点について、和田卓人氏は別の対談動画（ AI疲れとジュニアエンジニア育成、モブプログラミングの役割 ）で、次のように語っています。 コーディングエージェントによって、実行責任はエージェントへ、説明責任・品質保証は人間へ、という役割分担になっていく。テックリードが担っていた判断の負荷が全員に降りてきた。 AIが多様な要求に対して提案を返してくる中で、その判断を一人で全部こなすのは現実的ではありません。そこで和田氏が推奨していたのが、 モブプロの実施 です。 AI によってコード生成は十分に速くなっていたとしたら、人間はペアやモブを組む余裕があるはずです。複数人でエージェントと関わり、即時に判断していく。この判断を複数人ですることで、知識移転（教育）も行える可能性について言及していました。 そして、この「リソース効率からフロー効率への転換」と「教育」の重要性は、別の動画（ シニアのゲームに巻き込まれるな ）でも触れられています。 「AIで1日のプルリク量が何倍に」「数日で個人開発アプリを完成」という SNS 投稿に踊らされてはいけない。シニアには元々の積み上げがあるため同じ土俵では勝てない、という主張は、私としては耳が痛い話でした。 圧倒的な積み上げがあるシニアエンジニアと同じ土俵で戦おうとすれば、経験の少ないエンジニアは疲弊し、学びの機会を失います。私も、特に言われたわけではないですが、物的生産性にとらわれて、AIにコード生成させたりレビューさせて、そのまま使うみたいなことがありました。これを、意図的にやっているというより、誰からも要求されていないのに、無理して成果を出そうとしていたなと反省しています。物的生産性を多少下げてでもモブプログラミングの場にジュニアを巻き込み、「チームとしての判断力」と「教育」を両立する構造を作ることが、AI時代には不可欠ではないかと考えています。 開発プロセス：変わらないものと、Agent Skills による専門知識の言語化 AI時代になっても、チーム開発のプロセス全てがひっくり返るわけではありません。Sansan株式会社（笹川裕人氏）のセッションでも、「スクラム等のプロセスの本質（経験的に起きる課題への対処法）は変わらない」とはっきり言語化されていました。 一方で大きく変わるのは、AIという新しいメンバーへの指示の出し方です。合同会社Have Fun Tech代表の曽根武友氏は、「 AI時代における具体と抽象の往復 - 日常にチャンスがある 」というセッションの中で次のように語っていました。 AIへの指示も、結局は人間同士のコミュニケーションと同じ原理。「いい感じにして」が伝わらないのは、プロンプトの抽象度と相手（AI）の抽象度が一致していないから。 具体化には知識が必要であり、相手のドメインで話すにはそのドメインの知識が要る。 この「『いい感じに』という抽象的な指示を具体的な手順に変換するための知識」の重要性は、Anthropicの講演「 Don't Build Agents, Build Skills Instead 」でも強く主張されています。エージェントという曖昧な存在にすべてを丸投げするのではなく、特定のタスクを遂行するための「Skills（専門知識のパッケージ）」を構築すべきだというのです。 AIに的確な指示を出すための「Agent Skills」の整備は、単なるツールの設定ではありません。 チーム内の暗黙知を言語化し、共有知にしていくプロセスそのもの なのです。 国内の企業では、すでにこの「個人の暗黙知から組織の共有知へ」という取り組みが始まっています。 株式会社タイミーでは、「 Agent Harness Group 」という組織を立ち上げ、「個のAI活用」から「組織のAI駆動開発（AI-DLC）実践」へと協業を推進しています。また株式会社LayerXでは、モバイルチームで「 Claude Code Subagents祭 」と題した社内イベントを開催し、属人化しがちなAIへの指示やプロンプトをチームの共有知へと昇華させています。 私自身が推進しているAIエージェント活用においても、ここが最大のポイントになると感じました。単にAIツールを導入するだけで終わらせるのではなく、 Agent Skillsという機能を、AIというメンバーに暗黙知を伝える手段や、組織のベストプラクティスを誰もが簡単に再現できる方法として利用するための仕組みを作っていきたい と考えています。それこそが、AI時代における組織の長期的な競争力の源泉になるはずです。 学習：焦らず、理解を放置しない AIエージェントがコードを爆速で生成してくれる時代において、私たちが個人として取り組むべき最も重要なアクションは、「分からないところを放っておかない」という基本的な学習姿勢です。 Tech Lead Conference 2026でのセッションを通じて、登壇者三者の主張が見事に一致していたのが、この「継続的な学習の重要性」でした。和田卓人氏は、学習について次のように語っていました。 新人は、焦らずに学んでいく必要がある。自分がわからないところを放っておかずにやっていく必要がある。質を下げればスピードが上がるわけではない。トレードオフなのは教育である。質とスピードを担保させるために、教育することが必要になる。 曽根武友氏も、AI が発展しても変わらないこととして「 抽象と具体の往復スキル、ドメイン知識、継続的な学習 」を挙げていました。仕事の形は変われど、この往復の精度を上げることが本質である、と。 さらに、Sansan株式会社 のセッションでも、エンジニアのキャリアパスについて語られていたところで、「 仕事の総量は変わらない——AI で効率化されても別の仕事が生まれる。継続的な学習の必要性は変わらない 」という言葉がありました。この三者の主張は完全に一致しています。 『良いコード／悪いコードで学ぶ設計入門』の著者であるミノ駆動氏も、AI時代に漠然とした不安を抱えるエンジニアに対して、動画（ AI時代に“伸びる人・終わる人”の決定的な差 ）で次のように指摘しています。 漠然と不安に思っている人は、技術を学んでスキルアップすることが不安の解消に繋がっていると思えていないのではないか。不安を覚えるのなら勉強しましょう。 ミノ駆動氏は、AIは「ネット上の学習内容の平均」に収束する傾向があるため、設計的に問題のある構造でも技術知識がなければ素通りしてしまうと語っています。 AIが60〜70点のものしか出せないのは、指示する人間の基礎力（問題を見抜く力）が足りていないから でもあるのです。 また、ファインディ株式会社の高橋氏の動画（ ジュニア育成と組織学習 ）では、AI時代のエンジニア評価について、次のような組織側の変化が語られていました。 機能を何個作ったかっていうよりも、何を学んだかをアピールする時代になってきている。 これは個人の姿勢だけでなく、組織側にも問われることです。アウトプットの量だけを評価指標にすると、生成AIでいくらでも量産できてしまい、本当の力が見えなくなります。「何を学んだか」を評価し、基礎力を高め続ける仕組みを持っているかが、これからの人材育成の分かれ目になります。 最後に、和田卓人氏が別の対談動画の結びで語った、若手エンジニアに向けた言葉を引用します。 自分の能力をコツコツ上げていくことが、自分の競争力を上げていくことにそのままより大きく繋がる時代になってきたと思ってください。…（中略）… 焦らずにコツコツやっていけばいい。希望を持つ上でのコツは、人と比べないことです。比べるのは過去の自分です。 SNSを見れば、AIを使って爆速で開発している人がいくらでも目に入ります。しかし、そこで焦って理解を放棄するのではなく、自分の分からないところを放置せずにコツコツと基礎を積み上げていく。それこそが、AI時代を生き抜くための最強の生存戦略なのだと、改めて心に刻みたいと思います。 まとめ：教育とフロー効率を両立する3つの方向性 4つの観点を通じて感じたのは、ひとつの共通したメッセージでした。 AI は「理解の代替」ではなく「理解の加速器」として使う。 そのために、私たちが明日から取れる具体的なアクションは、以下の3つに整理できると考えています。 1. 物的生産性に流されず、対象への「理解」を深める姿勢と仕組み化 AIによる爆速なコード生成に流されず、「自分が理解できないもの」を放置しないことが第一歩です。分からない概念があればAIに説明させて基礎をコツコツ積み上げる「個人の学習姿勢」を持つと同時に、Test First でざっくり任せる領域と、Diffの小さいTDDのサイクルで回す領域を分け、人間の認知負荷を意図的に下げる「開発の仕組み」を取り入れること。アウトプットの量ではなく、「何を学び、どう理解したか」を重視する姿勢が問われます。 2. モブプログラミングによる判断とレビューの分散 一人がエージェントと対話して爆速で開発するリソース効率の罠から抜け出し、複数人のチームで専門性を持ち寄りながら判断するモデルへ。チームにジュニアが参加することで意思決定の OJT にもなる——教育とフロー効率の両立策として、今後試していきたい方法論です。 3. Agent Skills による組織のベストプラクティスの再現 「いい感じに」という抽象的な指示を具体的な手順に変換する Agent Skills は、単なるツールの設定ではありません。 チームのベストプラクティスを「AIという新しいメンバー」に伝える手段 として捉え直す必要があります。 実際に、株式会社タイミー では「 Agent Harness Group 」を立ち上げて AI との協業を組織的に推進していますし、株式会社LayerX では「 SubAgent 勉強会 」という知識共有の場を作っています。誰もが組織のベストプラクティスを簡単に再現できる仕組みを、社内でも作っていきたいと考えています。 おわりに AI にとってかわられる恐怖よりも、学ぶべきことの多さに恐怖している——というのは、裏返せば「学べば学ぶほど武器になる」ということでもあります。Tech Lead Conference 2026 で登壇者たちが口を揃えて言っていたのは、「 基礎知識を持つ人間がこれまで以上に価値を持つ 」ということでした。 特に4年目という、中途半端な立ち位置にいる自分にとって、和田卓人氏の「焦らずコツコツ自分の能力を上げていけば、それがそのまま競争力につながる時代になってきた」という言葉は、強い励みになりました。 焦らず、分からないところを放っておかず、基礎をコツコツ積み上げていく。その上で、AI を理解の加速器として使う。それがAI時代にエンジニアとして今後も活躍するための必要な考えかもしれません。 最後まで読んでいただきありがとうございました。