アーカイブ動画

基調講演：LLMをつくっているのは、どんなエンジニア？－NTT tsuzumiの事例－

エンジニアが生成AI導入を通すための社内説得術 - ユニファの実践事例から

ユニファ株式会社
AI開発推進部
田渕 梢（たぶち・こずえ）氏

最初に登壇したのは、ユニファ株式会社でAIアプリケーションエンジニアとして、AIを主軸とした新規プロダクト開発に従事している田渕氏。同社に在籍して2025年で10年。ほぼ創業メンバーの一人でもある。

同社は保育園、幼稚園、こども園向けの保育総合ICTサービス「ルクミー」を開発・提供している。例えば、連絡帳アプリはその代表例だ。「従来手書きだった連絡帳をアプリ化することで、手書きの負担を軽減し、保護者との連絡も容易になります」と田渕氏は話す。AIを活用したサービス群「ルクミー保育AI」も提供。これは、AIを活用した一連のサービスの総称である。過去に残した写真や連絡帳の記録をすばやくレポートとしてまとめてくれる新サービスなど、様々なサービスがある。

AIをプロダクト開発に活用するためには、予算を獲得することが必要になる。なぜ、現場の開発エンジニアが予算の話をするのかと疑問に思う方もいるかもしれない。田渕氏が所属するAI開発推進部は、AI導入や社内普及によって会社に利益を生むことが同部のミッションになっている。そのため、「例えば仕事の効率が良くなったとしても、高額なツールを使って結果的に会社に損失を与えることになるのはNGなんです」と田渕氏は言い切る。AI開発推進部のメンバーは皆、企画・開発時点から費用対効果について強く意識しているという。また、部に所属するメンバーが少なく、職種の区別があるようでない状況になっている裏事情もあるという。

「AIツールを使いたいけど、予算申請が通らない」
「効果を説明しろと言われても、使ってみないとわからない」
「経営陣にどう説明すればよいかわからない」

これらは、AI活用を考えている多くのエンジニアが苦慮するポイントだ。このような状況を田渕氏はどう打破したのか。「プロトタイプの開発にAIを利用して、効果を可視化しました」と話す。

従来のプロトタイプ開発では大きく3つの課題を抱えていたという。

第1の課題が「リソースの確保」。プロトタイプといえ、システムを作るとなると最低でも2～3人のエンジニアが必要になる。内製でやるには、余剰なリソースが無いことも多く、プロトタイプを開発するために既存の開発を止めるのかという議論になってしまうこともある。また外注にお願いしようとしても、教育コストもかかり、キャッシュアウトが発生してしまうため、「あまり良い選択とは言われないことが多い」と田渕氏は言う。

第2の課題は「コスト制約」。「潤沢な予算がないことが多い」と田渕氏。プロトタイプ時点ではプロダクトの利益は未知数だからだ。

第3の課題は「スケジュール」。リソースやコスト制約があるとはいえ、のんびりつくってよいわけではない。その後の展開を考えると、少しでも早くプロトタイプ開発をしてほしいとリクエストされることが多い。

「特に私が在籍するようなスタートアップでは、リリースのスピードは会社の生命線。なのでとても重要視されます」（田渕氏）

プロトタイプ開発にAIを活用し、効果を可視化

これら3つの課題を軽減し、かつAIツールの予算を取る方法として、田渕氏が考えたのが、「社内向けのプロトタイプ開発プロジェクトでAIを使って効率化し、費用面やビジネス面の効果を可視化する」という方法である。

今回、開発したのは社内向け音声記録システム。音声録音・文字起こし、テキスト入力、AI要約機能、ユーザー管理機能を搭載。文字起こしは、自動音声認識サービス「AWS Transcribe」のリアルタイム文字起こし機能、AI要約は「Amazon Bedrock」の「Amazon: Nova Lite 1.0」モデルを利用するなど、AWS上で稼働するシステムである。

開発は7月9日に始まり、8月12日に完了。期間にすると34日だが、実働は18日。しかも、少し前まで田渕氏はエンジニアチームの部長を務めており、現在もQA課の課長を兼務しているため、7月と8月の間に年度末評価や部署の期初準備で「2週間ぐらい開発できない時間があった」と明かす。そのため、実質工数は10人日くらいになるという。

今回のAIを活用したプロトタイプ開発の実績を数値化すると、開発期間が1.1カ月、開発人数が1人なので総開発工数は1.1人月、コード行数は約10万行となった。今回のアプリケーションの複雑度や技術難易度、10万行のアウトプットなどから逆算して従来手法による実績を推定。AIを活用した場合と従来手法を比較したところ、開発期間は三分の一になり、開発工数は約90％削減するなど、「大きな効果が得られた」と田渕氏は話す。

同時にビジネスに対するインパクトについても仮説を立てて検証。従来手法だと社内フィードバックを受けるタイミングは11月になるが、AIを活用すると1カ月で開発は終了、フィードバックも8月中には受けられるため、スケジュールを3カ月前倒しできるようになるという。

「ビジネスはスピードが大事。そういう意味でもAIを活用した開発はビジネス上も大きなインパクトを与えると考えられます」（田渕氏）

AIを活用した開発の効果を可視化することで、エンジニア以外にも導入の効果が見えやすくなり、さらに経営陣への説明では「費用対効果の側面で大きな関心と理解をいただくことができた」と田渕氏。今後の予算計画にも好影響を与えてくれることが期待されるという。「プロトタイプ開発においてはAIツールの導入による費用対効果が大きいため、今後も積極的な活用を推奨していく」と田渕氏は語る。

AIを使いこなせないエンジニアは生き残りが難しくなる

続いて田渕氏はAI時代のエンジニアの役割についても私見を述べた。「今後、AIを使いこなせないエンジニアは生き残りが難しくなっていくと思います」と田渕氏は言う。AIを使ってどんな風に会社に貢献できるのかが問われる時代になっていくと考えられるからだ。

一方で、AIツールの活用に積極的ではない会社があるのも事実。だが、そんな状況を変えられるのもエンジニアだという。その際に重要になるのが、「説得する相手に合った指標で話をすること」と田渕氏は指摘する。田渕氏もChatGPTが話題になったあたりから、Botを作成するなど、あまりお金をかけない範囲で社内での活用実績をつくり、徐々に周囲の理解を深めていってもらったという。

「経営陣相手に説得するときにはとにかく、エビデンス集めが大事。その作業にAIツールを使ってみる。AIを使いこなせるエンジニアになるために、自分で機会をつくりましょう」（田渕氏）

生成AI時代を生き抜くエンジニアの基礎力：速さと柔軟性を支える土台づくり

ファインディ株式会社
CTO室 開発推進 山岸 真悠子（やまぎし・まゆこ）氏

続いて登壇したのは、ファインディ株式会社CTO室 開発推進の山岸 真悠子氏。同社は「つくる人がもっとかがやけば、世界はきっと豊かになる。」という経営理念の下、主にエンジニアを対象にしたプラットフォームを開発している。フロントエンドを主軸にしてきた山岸氏が同社に入社したのは2024年10月。現在は「Findy AI+」の開発に取り組んでいる。

「Findy AI+」は生成AIのアクティビティを可視化し、生成AI利活用のボトルネックを発見するなど、生成AI活用の推進をサポートするプロダクトである。「田渕さんも言われていたように、これからはROI（投資利益率）が問われてきます。『Findy AI+』はそのための可視化をサポートします」と山岸氏は説明する。具体的にはClaude Code（クロードコード）のプルリクエスト数やマージ率、任せたタスクの種類などが可視化できる。

また「Findy AI+」は「MCP（Model Context Protocol）という最新技術も取り込んでいます」と山岸氏。MCPとはAIモデルとGoogle Driveツールやデータソースを安全に接続するための通信規格で、「AI統合におけるUSBのような役割といわれている」と山岸氏は言う。

MCPを使うことで何が変わるのか。その事例として紹介したのが管理画面。一般的なWebサービスでは、認証などを入力する管理画面を用意することが多い。だが「Findy AI+」では「Visual Studio Code（VS Code）のAgent modeを使うことで、自然言語で管理機能を実行できるようにしました」と山岸氏は語る。

例えば「○△組織」の追加をする場合も、チャット画面に「○△組織を追加してください」というプロンプトを投げると、「Findy AI+」のアドミンMCPサーバーが起動。本当に追加しますかと聞かれるので、Yesと回答すると、追加できる。山岸氏を含めたエンジニア2人とPdM1人という最小のチーム構成ながら、約1カ月という爆速でα版のリリースができたという。

AIを活用して良かったポイント

AIを活用して良かったポイントは3つ。第1に開発工数が激減したこと。「AIによって画面やAPIを実装する必要がなくなったことが大きい」と山岸氏。また最小コストでプロダクトを世に出せたので、プロダクトの需要についても測ることができたという。

第2にコミュニケーションコストが激減したこと。AIによってチームメンバーが少ない分、タスクの振り分けやスケジュール管理、認識確認などが不要になったからだ。

第3に新しい領域へのチャレンジが容易になったこと。

「これまではバックエンドやインフラなど専門外の領域については、その領域の担当者に聞きにいく必要がありましたが、今はAIにコードを読ませることで、自ら仕様を取りにいけるようになりました」（山岸氏）

それだけではない。専門外の領域までタスク遂行ができるようになったという。これも「AIによって得られた恩恵」と山岸氏は言う。

具体的に「Findy AI+」の開発では、API仕様把握に加え、コードを書く、コミットする、プルリクエストを作成する、リポジトリを横断してアーキテクチャを探す、などのタスクをAIが実行。そのため山岸氏はほとんど手を動かさず、楽に開発できたという。

なかでも山岸氏が助けられた機能が、「Claude Codeのカスタムスラッシュコマンド」だという。.claude/commands/ディレクトリにMarkdownファイルを配置することで、個人またはチーム独自のコマンドが作成できるという。

これを使って3つのタスクを実行した。1つ目はブランチの作成。

「git-create-branch.mdというファイルを作成し、その中に[Conventional Branch]の命名規則に従って作成してください。ブランチ名はfeature/[FeatureName]-[実装した機能名]にしてください」というルールを記載するだけで、AIがこの手順通りに作業してくれたという。

2つ目はコミットメッセージの作成。コミット前に必ずコーディングガイドラインをチェックする、タイトルは50文字以内、動詞は原形を使用するなどの細かいルールを記載したという。

3つ目はプルリクエストの作成。「プルリクエストテンプレートを参照させることで、統一性を担保しました」（山岸氏）

またビジネスサイドとのコミュニケーションにもAIを活用。例えば、CLIでコードを読ませてシーケンス図を作成したり、Claude Codeアーティファクトでモックを作成したりして、プロダクトの方針の認識合わせを行った。「いずれも簡単に作成できます。コミュニケーションの面でも効果的でした」（山岸氏）

AI活用には即効性のある基礎力と持続性のある基礎力が欠かせない

AIを活用した開発によって、痛感したことがある。それは「基礎力がベースとして必要である」ということ。AIが提案してきたものは悪くないが、公式が発表しているベストプラクティスではなかったり、思わぬバグを生むこともあったりするからだ。

基礎力も「2軸ある」と山岸氏。1つは言語やフレームワークの使い方など、即効性のある基礎力だ。AIが古い言語バージョンで提案し、syntaxエラーが発生したことがあったという。そこで山岸氏は「syntaxエラーを解消せよ」とAIに指示。AIはエラーを解消するようコードを修正したが、公式が発表しているドキュメントを見に行くと、AIのコードとは乖離があった。

「一次情報を取りに行く姿勢も含めて、即効性のある基礎力は大事だと思います」（山岸氏）

もう一つが持続性のある基礎力。これは基本情報技術者試験に掲載されているような知識。山岸氏はフロンエンドを中心にキャリアを積んできたが、今回、「Findy AI+」ではバックエンドやインフラという領域にもチャレンジした。

「正規化やデータベース操作、CORS（同一オリジンポリシー(SOP)の制限を回避する際に利用する機能のこと）などの知識がなければ、1人ではタスクは遂行できなかったと思う。AIによって新しい領域にチャレンジしやすくなったからこそ、事前の知識に大きく助けられました」（山岸氏）

またAI時代のキャリアについても自身の考えを述べた。「最新技術が使える環境に身を置けたのは大きなチャンスだった」と振り返る。今のチームは少人数で自然にAIの最新情報が入ってくる環境。だが、以前はAIを組み込まれていないプロダクトチームに所属していたので、自ら情報を取りに行かなければならないなど、常に焦燥があったという。

「自分のキャリアを考えたときに、自然にAIの最新情報が入ってくる環境に身を置くことも大事です」と山岸氏は力強く語った。

生成AIで進化するAWSコスト最適化戦略 : エンジニアの時間を取り戻そう

アマゾン ウェブサービス ジャパン 合同会社
技術支援本部　テクニカルアカウントマネージャー
岡田 亜希子（おかだ・あきこ）氏

最後に登壇したのは、アマゾン ウェブサービス ジャパン合同会社（以下、AWSジャパン）の岡田氏。岡田氏はAWSジャパンでテクニカルアカウントマネージャー（TAM：Enterprise Supportを契約しているお客さまに、主に運用観点で利活用や改善を中長期で支援する）というロールを担っている。

まず、岡田氏が解説したのは生成AIによる現場のコスト最適化戦略の進化について。クラウドのメリットとして、よく挙げられるのがすぐにリソースを調達できること。だが、余剰リソースはない、最適サイズでつくっていると言い切れる人は少ない。岡田氏自身も「大きく作って、いつ戻そうかなと考えた経験がある。最初から最適なリソース計画でリリースするのはなかなか難しいうえ、いつでも変更できるので、運用しながら最適化すればよいという前提で進んでいくことも多いと思います」と語る。

だが実際に運用が始まると、最適化のための人員や時間を確保するのは難しく、後回しになってしまうケースも多くある。また最適化は一度で終わる仕事ではなく、常に最適な状態は変化するので、システムを使っている間は常についてまわる課題でもあるという。

コスト最適化にまつわる課題としてよく挙げられるのが、「リソース管理がいろいろな場所に分散していて可視性の確保が難しい」「常に変化する需要に対応する時間がとれない」「コスト最適化は意外と属人化しやすく、職人頼りになってしまう、それゆえ手動プロセスが排除できず、最適化が非効率になってしまう」という課題。

クラウド運用にまつわる課題を「Amazon Q Developer」で解決

だがこれらの課題に対して生成AIを活用するとどうなるか。

「可視化については専門知識がなくてもレポートが作成できるようになり、常に変化する需要については、いつでも気軽に取り組めるようになります。また専門知識の不足については、職人技が不要で誰でも取り組める仕組みの構築が可能になり、たくさんの手動プロセスで時間がかかっていた作業は、短時間かつ自動で分析を完了させることが可能になります」と岡田氏は語る。

具体的な方法として、岡田氏が紹介したのは「Amazon Q Developer」を使用した事例。「Amazon Q Developer」は開発者のアプリケーション開発をAWSの専門家として支援し、実装面での専門的なアドバイスやエラー発生時のトラブルシュート、AWSリソースの管理や最適化に利用できるツールである。

活用場面として岡田氏は2つを紹介。1つが自然言語処理によるコスト分析レポートの自動生成である。

「毎月、色々なところからデータを集めてきて、職人が作っていたようなレポートをアカウントの利用者自身が簡単に作れるようになります」（岡田氏）

不要かもしれないリソースの洗い出しや「Amazon EC2インスタンス」など、最適なサイズの提案もやりやすくなるという。

もう一つがコスト最適化戦略の策定への有効活用。効果測定を基にした取り組むべき優先順位の策定などが検討できるようになる。具体的な例として岡田氏が挙げたのは、「Amazon EC2 リザーブドインスタンス」購入と、土日夜間に停止した場合を比較して、利用していない時間帯に自動的に停止し・起動してもらうという使い方。「これらを『Amazon Q Developer』では、ユーザーの自然言語から最適なAWS CLIコマンドを選択して、実際のリソースの情報を確認しながらIAMで付与された権限の範囲内で実行することができます」（岡田氏）

また属人化しやすいという課題も、「Amazon Q Developer」なら解決できる。

「Amazon Q Developer」はエージェントとコンテキストを利用できる。これにより「日々のコスト最適化の負荷を軽減し、時短の実現につながる」と岡田氏は言う。

コンテキストに、どんな項目を確認してほしいのか、「Amazon EC2インスタンス」のサイズの最適化なのか、RDSはそっとしておいてほしい、どこからもマウントされていないEBSを徹底的に見つけてほしいなど、さまざまな条件を記すことで、AIエージェントに前提知識を理解してもらう。エージェントがユーザーの意図を正確に理解できるようになり、プロジェクトの実態に即したコスト最適化職人エージェントを作ることができるようになるという。

コスト分析用以外にも、エージェントは開発用、レビュー用など用途ごとに作成することができる。それらのエージェントごとに確認してほしい内容や背景などを設定して、前提条件を読み込ませることができるのだ。「コンテキストは自然言語で書くことができます」と岡田氏。書き方は次の図の通りだ。

コンテキストを作るのに時間がかかりそうと思う人もいるかもしれない。だがそういった心配は不要だ。コンテキストがあればより状況に応じた分析ができるようになるが、「なくてもレポートは作成できる」と岡田氏。「Amazon Q Developer」では一般的な知識に基づき、コスト最適化余地のある項目を洗い出してくれるからだ。使用しているリソースの確認だけではない。これから構築するリソースの最適化戦略についても相談することもできるという。

「まずはコンテキストなしでレポートを作成し、どんどん便利にしていけばいいのでは」と岡田氏はアドバイスする。

「Amazon Q Developer」によるコスト最適化の導入によって現場はどう変化するのか。CCoE（Cloud Center of Excellence）が分析をし、現場に対応を依頼していたような現場では、分析して現場に依頼をするものの、適切ではない指摘が含まれたり、指摘されたリソースの確認に時間がかかることもあったという。だが導入後は現場で集めたコンテキストを分析に活用することで、無駄な指摘が減り、現場の対応もスピードアップ。また現場が直接、効率の良い削減方法や妥当性を「Amazon Q Developer」に相談できるので、結果として現場の対応時間が短縮され、コストが最適な状態になるまでの時間が削減されたという。

「『Amazon Q Developer』を活用したコスト最適化では、職人技が不要で誰もが短時間で最適化に取り組むことが可能です。捻出できた時間やコストは、事業投資やよりよいプロダクト改善、エンジニアの自己研鑽に有効活用できると思います。これからは生成AIでコスト最適化戦略を進化させる時代です」（岡田氏）

生成AI時代のキャリア戦略は「とにかくおもしろがる」

続いて岡田氏は生成AI時代のキャリア戦略について解説。「結論としては、とにかくおもしろがって進むこと」と岡田氏は言い切る。

とはいえ日々の仕事でおもしろさを感じるのはなかなか難しい。そこで岡田氏が提案するのは「おもしろいと思える感受性を育てること」。感受性を育てる場はプライベートでもいいという。好きなことを思い切りやり、どういうことが自分の心を動かすのか、内省していくことで、おもしろいと思える感受性を育てることができるという。

そのほかにも生成AI時代のキャリア戦略のポイントとして岡田氏が挙げたのは、生成AIとの協業を考えられるようになること、自分を拡張するために生成AIを活用すること、ビジネスやお客さまの背景を理解することである。

「まだまだ取り組む課題はたくさんあります。そしてそれらはものすごいスピードでやってきます。これらをおもしろがってやっているのと、いやいややっているのとでは、差が生まれます。普段から好きなことをして、楽しみながら暮らし、おもしろいと思える感受性を育てていく。そうすることが私たちのキャリアを育ててくれると思います」（岡田氏）

【Q&Aセッション】

セッション終了後、質疑応答の時間が設けられた。岡田氏がファシリテートを務めた。

Q.プロトタイプ開発では、どのくらいの頻度でAIを活用していますか。

田渕氏：AIをプロトタイプに活用するようになり、頻度が格段に上がっていて、プロトタイプに至る前の技術検証や確認なども含めると、1カ月間で2つか3つは何かしら作って動かしています。

山岸氏：断定はできないんですけど、AIが出てきたことによってプロトタイプ作るハードルが下がったというのは間違いなくあるので、頻度としては増えている印象があります。

岡田氏：私はインフラエンジニアなので、これまでコードはほぼ書いたことはありませんでしたが、最近はAIを活用してプロトタイプを作ってお客さまに持っていくことが増えています。時代は変わってきていると感じています。

Q.AIツールをいろいろ使ってみたいが、どう上司に説明すればよいか悩んでいます。説明するコツを教えてください。

田渕氏：説明のコツはセッションでも伝えたように、まずは相手が何を心配しているのかを分析すること。そしてそのためのエビデンスを積んでいく。ツールごとに特徴も異なるので、そこを含めて可視化してそれを基に説明すると良いのではないでしょうか。

山岸氏：コストに対する利用度、効果を可視化することで説得できるのではと思います。

岡田氏：そうですね。効果を見えるようにすることが大事だと思います。

Q.シンプルな機能のプロトタイプとプロダクトのコードでは複雑性が異なると思います。プロダクトに活用するには、どのように説得すればよいのでしょうか。

田渕氏：今回紹介したAI活用による作業のコードの正確性や作業効率はプロトタイプに限ったもの。コード量が多い既存のプロダクトへの活用では、全く異なる結果になると思います。プロトタイプへのAI活用の可視化はできたので、現在は実際のプロダクションでもコーディングにAIを活用するとどのくらいの効果が出るか、可視化の第二段に取り組んでいるところです。気をつけたいのは、開発メンバーの人数削減につながるような流れにしないこと。そこもきちんと話すことが大事だと思います。

山岸氏：「Findy AI+」は新規事業なので、プロトタイプへのAI活用との相性はよかったのですが、既存のシステムだと複雑性が増すのでAIとの相性は難しいと思っています。

Q.経営陣を説得する方法について教えてください。

田渕氏：懸念点にフォーカスを充てることです。阻害要因として多いのが、セキュリティやハルシネーションの問題。ですが、それらに関するドキュメントもたくさん出ているので、それらを参考にしたり、AIに相談するというのもいいと思います。

山岸氏：私もAIに説得術を相談するのは良いアイデアだと思いました。

岡田氏：AIに相談する際、AIに前提知識として、例えばクラウドを導入した時の記録など、過去の説得した会話の記録を持たせると良い回答が出てくると思います。

Q.AI時代における学びとキャッチアップの方法について教えてください。

田渕氏：SNSを活用しています。私のXのアカウントは情報収集用。AIに関する情報を発信している有名な方をフォローしてキャッチアップしています。また教えることに特化したAIを活用して、勉強しています。

山岸氏：基本情報技術者試験の勉強はお勧めです。私も教本で勉強をしています。また最新のAIの動向については、OpenAIやVisual Studio Codeのリポジトリの通知機能を使ってキャッチアップしています。

Q.AIが生成したコードの信頼率や手直し率などについて教えてください。

田渕氏：AIが生成した段階で、1つずつコードを確認して修正しています。手直し率は体感で約2割。コードの信頼度は出す指示や、指示前の前提条件でも変わってくるので、そこの工夫は必要だと思います。

山岸氏：手直し率をマージ率に置き換えてお話しします。最初AIツールを使ってプルリクエストを作成したときはマージ率が低かったのですが、その原因はプロンプトにありました。AIがわかりやすい文章、箇条書きにするなどプロンプトを改善することで、マージ率は高まりました。

岡田氏：AIが生成したコードと書いてほしかったコードを比較して、どうしたらほしかった方のコードが出てくるのか、AIに聞いてみてもいいと思います。

Q.皆さんの面白いと思える感受性のポイントについて教えてください。

田渕氏：昔からSFが好き。当時SFだったものが今は実現してたりします。それに興奮しますし、仕事のモチベーションになっています。

山岸氏：最新の技術を使ったものを世に出したときに、どういう形で世間の人が受け入れるのかにワクワクします。今回、MCPを活用し、その反応を見られたことにおもしろさを感じました。

岡田氏：知らないことを知ることがとにかくおもしろい。それがおもしろいと思える感受性を育てることにつながっていると思います。

文＝中村 仁美

※所属組織および取材内容は2025年9月時点の情報です。

アマゾン ウェブ サービス ジャパン合同会社
https://aws.amazon.com/jp/

アマゾン ウェブ サービス ジャパン合同会社の採用情報
https://aws.amazon.com/jp/careers/newgraduate/