こんにちは、サイバーセキュリティと生成AI活用推進を担当しているたなちゅーです。この記事では、2026年2月に活動を開始したAI-Native Devプロジェクトについて紹介します。 活動の背景 2025年までの取り組み KTCでは2024年の 生成AI活用プロジェクト を皮切りに、2025年は「AIファースト」「リリースファースト」を掲げ、AI活用は着実に進みました。 AIファースト ：すべてのプロダクトへのAI統合、AIプロダクトの開発推進、グループ内でのAI活用ドライバー リリースファースト ：「いかに速く届けるか」を文化として組織に定着させる 「AIを使う」から「AIネイティブな開発・業務プロセス」へ こうした取り組みを経て、昨年末に副社長の景山がテックブログ「 2025年の振り返りと2026年の展望：Agenticな未来へ 」で、2026年のキーワードとして「Agentファースト」と「AIエンジニアリングファースト（AI-Native Dev）」を掲げました。 Agentファースト ：「対話するAI」から「行動するAI」へ。AIが自律的にタスクを遂行する世界を全社で実現する AIエンジニアリングファースト（AI-Native Dev） ：AIネイティブな視点で開発・業務プロセスを再構築し、職種の壁を超える 目指すのは、 一人ひとりがAIネイティブな視点で開発や業務のプロセスを変えていくこと 。その推進役として、2026年2月にAI-Native Devプロジェクトが発足。プロダクト開発からクラウドインフラ、コーポレート部門まで、10名超が合流した横断チームで活動を開始しています。 活動の2つの柱 個人の知見を組織全体で活かす仕組みと、それを支える開発環境の整備。この2つが揃って初めて組織として加速できると考え、活動を 文化醸成 と 開発環境整備 の2本立てで構成しています。 文化醸成 ：ナレッジの体系化・共有、AIツール利用状況の可視化、社内事例の発信など 開発環境整備 ：AI時代のコードレビュー最適化、AI Agent / MCP基盤の整備、エンバイロメント（環境）エンジニアリングなど Phase 1：まず土台をつくる Phase 1として取り組んだのは、活動の土台となる2つの基盤です。 AI Native Hub 1つ目は、社内Wiki上に開設した生成AI活用の社内ポータル「AI Native Hub」です。 職種別のAIツール活用ガイド、MCP・Skillsの使い方、社内事例などの情報を集約しています。また、コンテンツの運用にはGitHubを採用しています。Markdownで記述し、PRでレビューを回し、mainブランチにマージされると社内Wikiへ自動同期される仕組みです。運営チームだけが管理するのではなく誰でもナレッジを共有できる、社内全体で育てていくナレッジ集約場所を目指しています。 Claude Code Dashboard 2つ目は、Claude Codeの利用状況を可視化するダッシュボードです。Claude CodeのOpenTelemetryを活用しています。 ダッシュボードでは、MCPやSkillsの使用回数、利用者のトークン使用量、トークン使用量上位者のトレンドが見えます。自分の活用状況の振り返りやトークン使用量上位者との交流など、AIツール利用促進のきっかけになればと考えています。 Phase 2：実践と拡張 Phase 1は立ち上げと基盤整備。4月からのPhase 2は、その基盤の上で実践を加速するフェーズです。 文化醸成 文化醸成が目指すのは、AIネイティブな開発・業務のスタイルが組織に根づくことです。 もくもく会・ハンズオン会 ：気軽に情報交換できるオンラインの場を定期開催し、実践知を共有する AIネイティブな個人・部署へのインタビューとナレッジの横展開 ：先行事例を掘り起こし、他チームへ広げる AIネイティブな活動の可視化 ：AIネイティブ度合いを可視化し、活動の推進に活かす まず動き出したのが「もくもく会」です。週2回オンラインで開催して、ちょっとした困りごとやTipsなどを話しています。また、テーマを決めたハンズオン会も実施しており、初回の「Claude Codeを使い倒す設定を一緒にしよう会」には合計80名以上が参加しました。学びは集約して、後から参照できる形にしています。 開発環境整備 開発環境整備が目指すのは、AIエージェントを前提とした開発基盤を整えることです。 AI Agent / MCP基盤の整備 ：AI AgentやMCPの共有基盤の整備を進め、誰でも見つけて使える状態を目指します。 AI時代に合わせたコードレビューの最適化 ：AIが生成したコードに対するレビュー観点や静的解析との連携など、AI前提のレビューフローを検討しています。 エンバイロメント（環境）エンジニアリング ：AIエージェントが安全に活動できる範囲の境界線設計やガードレールなどの整備に取り組んでいきます。 既に社内ではエージェント開発・共有基盤「KTC Agent Store」を運用しており、現在は実行基盤をBedrock AgentCoreへの移行を進めています。AIエージェントとしてはAIインタビューという深堀りインタビューエージェントなどの開発が進行中です。 ここまでの活動で感じたこと 一番の発見は、AIネイティブな働き方に既に踏み出しているメンバーの多さです。初回ハンズオン会には80名以上が参加し、チャットではおすすめ設定や活用Tipsが飛び交いました。この熱量をつなげれば、もっと大きな力になる。その点と点をつなぐことがAI-Native Devの役割だと改めて感じています。 また、AIネイティブな開発・業務スタイルが根づけば、日々の業務から生まれた余力が新たな価値創出へ向かう流れをつくれるはずです。「攻めのAI活用」と「守りの安全基盤」の両面をつなぎながら、その流れを組織全体で加速させていきます。 おわりに AI-Native Devは始まったばかりです。土台を作るフェーズから、土台の上で走るフェーズへ。活動の進捗やナレッジは引き続きテックブログで発信していきます。 最後まで読んでいただきありがとうございました！

AIツールの進化が加速するなか、エンジニアの仕事はどう変わっているのか。日々の開発でAIを使い続けるエンジニア3名に、活用の実態から失敗談、半年後の開発スタイルの展望まで、本音で語ってもらいました。 登場人物 名前 役割 あさしん( @asashin227 ) （写真右下） 名古屋プロダクト部のエンジニアリングマネージャー。仕事でもプライベートでもAIをうまく使う方法を常に模索中。エンジニア以外でもAIを使えるようにスタメン内でのハンズオンやAIもくもく会を運営しています おしん( @38Punkd ) （写真左下） iOS開発を得意とするエンジニア。AIを使って積極的にAndroidやWeb技術にチャレンジ中。プライベートではAIでインフラ中心のエンジニアをしている いが( @cochumo ) （写真真ん中） フロントエンドを専門領域としているエンジニア。AIを使ってバックエンド開発にも軸足を伸ばしています。今回のインタビュアーも兼任。 1日の業務の50〜80%がAIと対話。コードの外にも使い道は広がる ── 1日の業務のうち、何%くらいAIと対話したり、作業を任せたりしていますか？ あさしん： ミーティングが結構多いので、思ったよりは使えていないんですよね。それでも50〜60%くらいにはなっていると思います。ミーティングの前に依頼しておいて、ミーティング後に確認みたいな使い方をしています。 おしん： 自分はあまりミーティングが多くないので、70〜80%は使っていますね。 いが： 60%ぐらいでしょうか。作るものの方向性についてメンバーとディスカッションする部分は人間がやらないといけないので、100%にはならないですね。 ── どんな場面でAIを活用していますか？ おしん： 仕様の方向性をまずAIと話して、提案の形に整えてから人間とのディスカッションに持ち込む流れが増えてきました。ステークホルダーへの合意形成の前段階だったり、CS（Customer Success）へのお知らせ文や顧客との調整の頭出しにも使っています。まるっと投げるというよりは、自分なりの仮説がある状態でブラッシュアップしていく、という使い方が多いですね。 あさしん： 最近はClaude Cowork（以下Coworkと表記）をコーディング以外の場面でも使えるようにしていきたいなと思っていて、少しずつ試しています。割合はこれからも増えていきそうだという感覚はありますね。 いが： Coworkいいですよね。社内のチャットのステータス変更の処理を自動化してスケジューリングさせるような使い方は、本当に助かっています。 スピードは上がった。でも、楽しさの「質」が変わった ── AI導入から、開発のスピード感や楽しさはどう変わりましたか？ あさしん： スピード感は確実に上がりましたね。やりたいことを自然言語で書けばとりあえず動く状態になるので、試行錯誤の回数が格段に増えています。ただ、仕事においては「プログラミングは自分がやらなくていい」という目標をもともと持っていたので、AIがコードを書くことへの心理的な変化はそれほどないというか。メンバーが書いてくれるのとAIが書いてくれるのとで、感覚的にはさほど変わらないんです。変わったと思うのは、人との解釈合わせにかかるコミュニケーションコストが減ったことです。AIへの指示は自分の責任で完結するから、より言語化の精度を上げないといけないという意識が強まりましたね。 おしん： 楽しさという意味では、むしろ大きくなりました。これまでネット上の記事を探し回ることに費やしていた時間をAIが肩代わりしてくれるので、「プロダクトの仕様をどう改善すれば売上に貢献できるか」という、本来考えるべきことに頭を使える時間が増えています。 いが： AIの進化にはワクワクするんですけど、AIに実装をやらせているとき自体はそんなにワクワクしなくなってきました。自分が書いていないからのめり込めなくて、複数のことを並行して浅く広く動かす形になってしまっている。コードを書いているときの楽しさは、正直なくなってきましたね。 おしん： ただ、その代わりに。職人的な充実感よりも、事業を前に進めている手応えに重きが移ってきた感覚がありますね。 ── 具体的に「これはAIにやらせて正解だった」という事例はありますか？ あさしん： テストケースを大量に作らせるのはAIが得意な領域で、活用しています。あとは先ほど触れたCoworkですね。カンファレンスのグッズを企画するときに、会話の中で出てきたアイデアをそのままデータ化したり、作ったデータをNano Bnanaで画像に合成して、それっぽいイメージを可視化できるのが便利でした。コーディング以外のプロトタイプも、以前より格段に作りやすくなっています。 いが： Coworkは自然言語で指示してワークフローを組むと、ブラウザ操作まで実行してくれます。そこが本当に大きい。こういった活用はこれからさらに広がっていくんだろうなと感じています。 ガードレールを引かないと、リポジトリもドキュメントも静かに汚れていく ── 逆に、失敗したことや、気をつけていることはありますか？ あさしん： 個々のミスというより、チーム全体として気になっているのはリポジトリに入っているドキュメントが少しずつ汚れていくことです。うちもそこまでドキュメントの文化が強いわけじゃないので、誰も深く見ていない箇所でAIが誤った内容を書き込んでいても気づけない。ガードレールをきちんと設計しておかないと、気づかないうちに的外れな方向へ進んでしまう。意識して向き合わなければならない課題だと思っています。 おしん： 嘘とまでは言えないけれど、根拠があいまいなままでも断言してしまうのがAIの特性だと思っていて。わずかでも事実と違う内容が混ざると、ドキュメント全体の信頼性が揺らいでしまいますよね。 いが： 仕様書をAIに書かせた場合でもユーザーインタビューに基づいた内容なのか、推測で書いたものなのか、根拠がまったくない記述なのか、読んだだけでは区別がつかない。その3パターンをちゃんと分類する仕組みを作って曖昧なところを明示的に固めていく、そういう工夫をこれからも続けていきたいですね。 ── プロンプトや指示の出し方で、自分なりにこだわっていることはありますか？ あさしん： まず一度考えさせる、というのは意識しています。「プランニングしてください」と明示的に書いてから進めるようにしていて。あとは、プロンプトで都度指示することより、ドキュメントを整えて自動的によい動きをしてくれる環境をつくることを優先していますね。スキルの整備やエージェントの動きを定期的に見直すのも続けています。週に一度くらいは、同じ作業を繰り返していたらスキルとして切り出す習慣もつけています。 セッションの履歴を見て、繰り返しやっていることをスキル化するのは効果的です。全セッションを遡る必要はなく、そのセッション内のやり取りから切り出すだけで十分なことが多い。CLI（Command Line Interface）やLSP（Language Server Protocol）をちゃんと使い込むと、その辺りがうまく機能すると思いますね。 これからのエンジニアに求められるのは、ドメイン分解力・抽象力・言語化力だ ── 半年後、自分たちの開発スタイルはどうなっていると思いますか？ あさしん： コーディング作業そのものは今より少なくなると思っています。その代わり、課題を持っているステークホルダーとのコミュニケーションがより重要になってくる。FDE（Forward Deployed Engineer）と呼ばれる役割、つまりお客さんの現場に立ってエンジニアとして提案していくような動き方も、これから注目されていくはずです。 いが： すでに別の会社では、CxO（Chief x Officer）にAI活用が得意な人を一人つけて、その人がやりたいことをPoC（Proof of Concept: 概念実証）化していくという動き方をしているところも出てきていますよね。 おしん： Figmaじゃなくてプロダクトレベルでのモックを素早く作る、という段階は確実に進んでいくと思います。エンジニアの強みは、やりたいことに対してどのアプローチが現実的かを具体的に示せる点にあります。自分のタスクや技術領域だけを見ていればいいという姿勢は通用しなくなって、事業全体を見渡して課題を見つけ動かしていけるエンジニアが、これからの開発を牽引していくと思っています。 ── AIが進化し続ける中で、エンジニアが磨くべき「コアスキル」とは何でしょうか？ あさしん： ITバブルの頃、エンジニアの工数が一番レバレッジが効くと言われていたのは、一人分の工数をかけることで、かけた工数をソフトウェアとして何万人というユーザーに展開できる、かけ算的な成長ができるからでした。今後はAIによってプログラミングが民主化されて誰もが主体的に開発できるようになってくる。そういった中で自分たちが発揮できる価値を捉えていく必要があります。アウトプットがソフトウェアである以上、ソフトウェアがわかる人向けの言語化の仕方はエンジニアならではの強みになると思う。 あとはロジックの破綻を整理してあげるとか、ドメイン駆動開発をエンジニアが担ってAIにドメインごとの指示を出していくとか、そういうやり方が主流になっていくでしょう。ドメイン分解能力、抽象能力、言語化能力、そして事業全体を俯瞰できる広い視野。自分のタスクだけ見ていればいいというエンジニアはどんどん淘汰されていって、事業全体から課題を見つけて推進できるエンジニアが成長して牽引できると思っています。 おしん： エンジニアの専門性はPMやデザイナーとも融合してきているし、モバイル・バックエンド・フロントエンドといった境界もなくなりつつある。そこをコアスキルにするのはもったいない。エンジニアが磨くべきは事業理解であり、事業ドメインをソフトウェア設計に落とし込んで、リリース後も安定的に運用できる力こそが本質なんじゃないかと思っています。 おわりに 今回はテックブログとしては新しい取り組みである「エンジニア3人でAI活用の座談会をする」という記事を作成しました。 AIを使える人と使えない人で、仕事の速さも質も変わってきており、何に注力して、何をAIに任せていくか、そして自身の思考をどこに使っていけばいいのかヒントが掴めたように思えます。 AIの使い方に正解はないからこそ、同じように模索しているエンジニアの方とお話してみたいと思っています。この記事が、そのきっかけになれば嬉しいです。 herp.careers 本記事はインタビュー音声をもとに編集・再構成しています。

はじめに みなさん、こんにちは。開発本部 アプリケーション開発部 Webフロント第2グループの佐々木大翔です。 普段は TypeScript や React などの枠組みの中で開発することが多く、DOM を直接触るような実装や Canvas での描画はほとんど未経験でした。 そこで今回は、Canvas を使って「マウス操作でグラフの見え方が変わる」アプリを個人開発してみて、学べたことをまとめます。 アプリを作ったきっかけ 所属グループで「もくもく開発勉強会」を実施しており、低レイヤー寄りの領域（DOM操作や Canvas 描画）も触って表現力を鍛えよう、という流れがありました。