はじめに こんにちは。職種横断ダイレクトリクルーティングサイト「ウェルミージョブ（旧カイゴジョブ）」でQAを担当している林です。 アジャイルな開発チームメンバーの一員として、よりよいQAを目指して日々トライを楽しんでいます。 エス・エム・エスではAIエージェントを積極的に業務へ活用しています。 ウェルミージョブの開発チームではGitHub Copilot、Claude Code、Codex、Devin、Geminiなど、用途にあわせて様々なAIエージェントやAIアシスタントを使っており、その中でも私はDevinというAIエージェントを主にQA業務に活用しています。 私はDevinを Slackのオープンチャンネル で使い、その経験を QAの事例共有会 で発表することで、活用方法を日々ブラッシュアップしています。 今日は、AIエージェントDevinをこっそり使わずオープンに利用することで得られたメリット、さらには職域を超えたDevinの活用方法についてもお話しします！ 0. Who is Devin？ Devinは、自律的にコードの作成・実行・テストまで達成するAIソフトウェアエンジニアです。（※参考： Devin公式ドキュメント ） プロダクトのソースコードを読み込んで調査やドキュメント作成を行ってくれるほか、プルリクエストの作成まで一手に引き受けてくれます。 AIエージェントを導入する際、真っ先に壁となるのが「機密情報やコードが外部に漏れるのでは？」という不安ですよね。その点、Devinは入力情報やソースコードの漏洩対策が徹底されています。オプトアウト設定を行えばデータ学習を停止できるため、情報流出を心配することなく安心して活用できます。 ※参考： Devin公式ドキュメント Devin を改善するために、どのようにデータが利用されますか？ 既定では、サービスの改善および強化を目的として、お客様のデータをモデル学習に利用する場合があります。有料プランをご利用の場合は、Data Controls 設定ページでいつでもオプトアウトできます。 また、個人のPC上で動かすだけでなく、SlackやTeamsなどのチャットツールのスレッドにメンションするだけでチームの会話へシームレスに参加させられる点も特筆すべき特徴です。 1. DevinをSlackのオープンチャンネルで使っています！ ウェルミージョブ開発チームでは、Slackに専用チャンネルを設けて「オープンにDevinを使える環境」を整えています。 このチャンネルには、開発やQAはもちろんデザイナー・インフラ担当・PdM・マーケター・データアナリストといったプロダクトに関わる多様なドメインのメンバーが参加し、それぞれの業務パートナーとして以下のように日々Devinを活用しています。 現行仕様や振る舞いの調査、フロー図やユーザーシナリオの作成 データ抽出用SQLクエリの作成（DBは直接参照せずにソースコードとスキーマ情報をベースにクエリを作成） テストケースやテスト手順書の作成、テストデータスクリプトの作成 障害の原因調査、障害修正プルリクエストの作成 インフラ関連の現状の設定の確認、修正やバージョンアップ対応用のプルリクエストの作成 新しい仕様についての相談、ユーザー要望をコードベースで整理・要約 ユーザー向け説明書の作成、ユーザー問合せを想定したご案内文面の作成 データアナリストが正しくデータを可視化・分析するためにDB情報を起点としたモデル挙動を調査 プロダクト関係者にも広く開かれたオープンな場所でDevinを使って実感した、 3つの大きなメリット をご紹介します。 1)「AIの使い方の知見」がチームに自然と伝播する。失敗も財産になる プロンプト作成やタスク設計に悩むメンバーであっても、オープンチャンネルでのやり取りをウォッチするだけで「適切な依頼の粒度」や「実践的な活用アイデア」を自走して学習できます。 さらに、失敗した際のリカバリー手順までオープンになっている点もポイントです。他メンバーの試行錯誤のプロセスまでも見られることにより、エラーへの抵抗感が薄れ、チーム全体の「Devin利用への心理的ハードル」を大きく下げる結果につながっています。 2)ブラックボックス化を防ぎ、周囲がフォローしあえる Devinとのやりとりはすべてオープンにしているため、Devinがもし見当違いな方向へ進みそうになっても周囲のメンバーがすかさずスレッドでフォローしてくれます。 実際にもらったアドバイスは多岐にわたります。 Devinの調査結果の抜け漏れの指摘 Devinが作成したテストデータスクリプトの不備をフォロー 『こう聞くとQAに役立つかも』といったプロンプトの提案 最近の大きな変化は、QAメンバーがDevinを活用して軽微なバグ修正のプルリクエスト作成を行うようになったことです。 QAとDevinのやりとりを開発エンジニアが温かく見守り、必要に応じてスレッドでフォローしてくれるおかげで、普段コードを書かないQAでも軽やかかつ安全にバグ修正ができています。 もちろん助けてもらうばかりではなく、私自身も他メンバーのスレッドに入ってハルシネーションを指摘したりよりよいプロンプトを提案するなど、自分の強みを活かして貢献しています。 3)フルリモートでも、周囲のメンバーの困り事や興味関心がわかる 現在私たちはフルリモートで業務を行っています。朝会・夕会や1on1などでコミュニケーションの機会は多いものの「廊下で会ったついでに軽くおしゃべりする」ような偶発的なコミュニケーションは生まれにくいのが現状です。 そんな中、Slackに流れるDevinへのプロンプトが予期せぬ架け橋になっています。他メンバーのプロンプトから「今どんな困り事に直面しているか」「何に興味があるのか」が自然と見えてくるのです。 そこから技術的な情報交換や課題解決に繋がるのはもちろん、興味関心から会話が広がったり、困っている仲間を労われたりと、メンバー間の心理的距離がより縮まる良いきっかけになっています。 また、Slackというオープンな場にDevinを招き入れた効果は、マーケターやPdMのコメントにも色濃く表れています。 マーケターの声: 「些細な疑問でもDevinに気軽に問いかけられるため、仕事のスピード感や精度、プロダクトそのものへの理解が大きく深まった」 「たまにスレッドの中でエンジニアの方がコメントしてくれたり、リアクションしてくれるのもSlackならではのポイント」 PdMの声: 「Devinは仕様特化エージェントと思っていて、コミュニケーションの中心であるSlackでやり取りできるというのは、活用や運用するという上では非常に相性がいい」 「ちょっとしたアイデアや壁打ちを常に開いてるSlackで思いついたら会話できるという体験は、イノベーションを生む」 気軽に使えるSlackでDevinをオープン運用する価値は、まさに想像以上です。 2. 社内コミュニティ「AI4QA事例共有会」で体験談を発表しました！ カイポケQA中村さんのテックブログ『QAエンジニアがAI活用事例を「全力でパクる」ための会をはじめました』でご紹介の通り、弊社ではプロダクト横断の社内QAコミュニティにおいて「AI4QA事例共有会」が開催されていました。 tech.bm-sms.co.jp 私は「Devinをオープンに活用する価値」を他のQAメンバーにも知ってもらいたいと強く思い、今まで2回にわたり活用事例を発表しました。 この発表を通じて、私は知見を広めるだけでなく、自分自身も 2つの大きなメリット を得ることができました。 1)QA視点のフィードバックを得て、活用方法をブラッシュアップできた 共有会では、1回目に『Devinの紹介とGOODな体験談』、2回目に『失敗談と新たなTRY』をテーマに発表しました。 視聴していたQAメンバーから現場ならではのフィードバックを受け取れたことは大きな収穫でした。作業に没頭していると見落としがちな視点や、次なる挑戦へのヒントを数多く獲得でき、フィードバックはすぐに取り入れて自身のDevin活用方法を即座にアップデートしました。 「コードを見る特性上、Devinのテスト観点はホワイトボックステストに偏りがちかも？」 💡言われてみれば確かにそう。「コード構造ベースではなく、ユーザー操作の視点でテスト観点を出して」と明示的に指示してみよう！ 「Devinが提案したテスト観点の中で『この発想はなかった！』というものはどれくらいある？」 💡Devinと自分の得意・不得意を常に意識し、お互いの弱点を相互補完していかなきゃ！ 「Devinに機能仕様書を作らせたり、テスト設計のレビューをやってもらったりできる？」 💡「そのうちやろう」と後回しにしていたレビュータスク。さっそく実践に移す！ 「Devinって使えば使うほど自動で賢くなるの？」 💡調べてみるとセッションは独立しており、単に会話を重ねるだけでは学習されないと判明。調査の過程でナレッジ機能や「DeepWiki」に出会ったので、こちらを活用してみよう！ 2)発表する前提でプロンプトを丁寧に言語化したら、いろいろな人が読みやすくなった AIエージェント利用時はどうしても「どう書けば思い通りの結果が得られるか」という目先のテクニックに意識が向きがちです。 しかし私は「共有会でDevinとのやりとりを紹介する」という前提を持つようになってから、プロンプトの記述を丁寧に言語化し、指示の背景やコンテキストまでしっかり補足する癖がつきました。 その結果、周囲のメンバーにとって理解しやすいだけでなく、Devinにとっても迷いのない高精度な指示が出せるようになりました。さらに、後から自分の過去プロンプトを見返す際も意図がひと目で分かり、次なるプロンプト改善の土台になるなど、巡り巡って自分自身の財産になっています。 番外編：開発・QAだけじゃない！職域を超えたDevinの活用方法 ウェルミージョブにおけるDevinの活用は、単なる『作業の効率化』だけに留まりません。開発・QA・デザイナー・PdM・マーケター・データアナリスト・社内システム管理者など職種の壁を越えたコラボレーションを生み、プロダクト開発全体の動きを加速させるポテンシャルを秘めています。ここからは、魅力的なDevinの活用事例を3つご紹介します。 1)DeepWiki Devinには、リポジトリ全体のアーキテクチャ図やドキュメント、ソースコードへのリンクを自動生成してくれる「DeepWiki」という機能があります。（※参考： Devin公式ドキュメント ） ドキュメントのメンテナンスは不要で、Wikiの再生成を実行するだけでDevinが最新のコードを読み解いて「システムの最新説明書」を自動で立ち上げてくれます。設定で日本語化も可能です。 AIがコードから読み取った説明書なので正式な仕様書そのものではありませんが、システム・機能の全体像やインフラ周りの情報を短時間でつかむ分には十分です。開発・QAだけでなく、プロダクトや機能をざっくり知りたいPdMなどのメンバーにとっても大いに役立っています。 2)リリースノート Devinに過去1週間で本番デプロイされたプルリクエストを抽出してもらい、その内容を要約してもらうことで『自動リリースノート』を生成させています。 単にプルリクエストを収集するだけでなく、要約のプロンプトを「コードを読まない非エンジニア向け」にチューニングしているのがポイントです。開発者以外のステークホルダーにとっても「何がどう変わったのか」が直感的に伝わる情報に整うため、プロダクトに関わる人へ幅広く重宝されるアウトプットになります。 3)社内ユーザー向けの仕様質問アプリ Devinの優れた『コード・仕様の調査能力』に目をつけたPdMが、その力を全社で還元すべく、Devinを用いた『仕様質問アプリ』を内製し社内リリースしてくれました。 Slack上でも仕様調査は可能でしたが、あえて「質問専用のインターフェース」を用意して用途を限定。これにより、Slackの操作に不慣れなメンバーでも直感的に使いこなせるようになり、以下のような大きな成果と可能性が生まれています。 双方ハッピーな体験：質問者はエンジニアの手を止めずに「即時回答」が得られ、エンジニア側は回答対応の割り込み工数を削減 ナレッジ化によるコスト削減：FAQとして過去の回答を蓄積・再利用することで、重複する質問への対応コストをカット プロダクト改善への還元：寄せられた質問ログを分析し、ユーザーが躓きやすいポイントを今後のプロダクト改善へと繋げていく予定 まとめ：オープン活用とアウトプットが生むナレッジの循環 今回ご紹介したように、Devinをオープンな場で運用・共有することには多くのメリットがあります。 チームへの波及効果: プロンプトや試行錯誤が可視化され、利用ハードルの低下と相互フォローの文化が醸成される 自身への還元: 共有を前提とした言語化により、プロンプト精度向上とナレッジの資産化が実現する 組織への広がり: 開発・QAにとどまらず、PdMやステークホルダー巻き込み型の活用へと発展する セキュリティ対策を整えた上で「みんなの見える場所でAIを使う」環境を作ることが、個人と組織双方のプロダクト開発能力を加速させる強力な基盤になります。 本記事が、みなさまのチームにおけるAIエージェント活用のヒントとなれば幸いです。 告知！ ウェルミージョブの開発をリードする @moro が、「 Kaigi on Rails 2026 」に登壇いたします。トークのタイトルは「 Event is what happens 」！過去3回のKaigi on Railsでも好評を博した@moroの講演にどうぞご期待ください！ 昨年までの発表 Simplicity on Rails - RDB, REST and Ruby / MOROHASHI Kyosuke - Kaigi on Rails 2023 Identifying User Identity / MOROHASHI Kyosuke - Kaigi on Rails 2024 Kaigi on Rails 2025 Keynote: dynamic!

オランダに住んでいる私は、電車で過ごす時間がかなり多く、たいていその時間を使って、ビルダーコミュニティが発信している内容をチェックしています。これまでは、そのためにノートパソコンを開いたり、スマートフォンでブラウザタブを操作したりする必要がありました。2026 年 9 月 21 日週、遅れている電車を待っている間に、AWS Builder Center のモバイルアプリでトレンド記事をスクロールしたり、ワークショップを確認したりしていました。そのおかげで、空いた 20 分間をとても有効に活用できました。そこで今週は、まず Builder Center モバイルアプリをご紹介できることをうれしく思います。 AWS Builder Center が iOS と Android のモバイルアプリとして利用できるようになり 、デスクトップやウェブ以外にもエクスペリエンスが拡張されました。AWS Builder ID を使用すると、サインインした状態を複数のセッションで維持しながら、トレンド記事の閲覧、600 以上の AWS Skill Builder コースへのアクセス、無料のサンドボックス環境を使ったハンズオンワークショップの管理を、モバイルデバイスから行えます。AWS Heroes、Community Builders、User Group Leaders をフォローしたり、外出先から Builder Loft のイベントカレンダーを確認したり、購読しているトピックやコミュニティのプッシュ通知を受け取ったりすることもできます。また、このアプリは Wishlist 機能にも対応しており、製品に関するフィードバックを AWS チームへ直接送信できます。Apple App Store および Google Play Store で世界中から利用できます。 Builder Center には今週、さらに 2 つの機能が追加されました。 Polls を使うと、ホームフィードからコミュニティに質問できます。質問を入力し、2～5 個の回答候補を追加して、期限を設定すると、ユーザーが投票できます。結果は随時更新され、コメント欄で議論することもできます。投票は匿名で、作成者には集計された数とパーセンテージのみが表示されます。一方、 Zero to Shipped ハッカソンは、9 月 18 日から 10 月 2 日まで開催されています。コーディングエージェントを AWS に接続し、実際に動作するアプリケーションを構築して AWS 上で公開すると、総額 28,000 ドルの賞金プールの一部を獲得できるチャンスがあります。受賞する 5 つのプロジェクトには、それぞれ 5,000 ドル分の AWS クレジットと AWS Builder のグッズセットが贈られます。 9 月 14 日週のローンチ 9 月 21 日週は、このほかにも次のような発表がありました。 Amazon Connect Talent が一般提供を開始しました 。Amazon Connect Talent は、大規模な採用活動を行う人材獲得チーム向けの、AI を活用した採用ソリューションです。Amazon が長年培ってきた採用ノウハウを基盤としており、AI エージェントを使って構造化された音声面接を実施し、エビデンスに基づく評価を行い、候補者を一貫した基準でスコアリングします。これにより、採用担当者は最終判断に集中できます。候補者は、どのデバイスからでも 24 時間 365 日面接を受けることができ、採用担当者はスコア、文字起こし、詳細な評価結果を翌朝確認できます。AI による評価中は、候補者のすべてのデータが匿名化されます。また、各コンピテンシーは評価基準に基づいて採点され、すべてのスコアは面接中の具体的な根拠と紐付けられます。さらに、採用担当者はすべての採用について最終的な意思決定権を維持します。一般提供版には、コンピテンシーに基づく評価、適応型の質問を行う AI 主導の音声面接、ブランドに合わせてカスタマイズ可能なモバイルファーストの候補者ポータル、管理者向けオンボーディングツールが含まれています。 Amazon Corretto 27 が一般提供を開始しました 。Amazon Corretto 27 は、無償かつマルチプラットフォーム対応の OpenJDK ディストリビューションの Feature Release 版で、Linux、Windows、macOS 上でダウンロードして利用できます。サポートは 2027 年 4 月まで提供されます。主な機能として、すべての環境で G1 がデフォルトのガベージコレクターとして採用されたこと（JEP 523）、TLS 1.3 向けの耐量子ハイブリッド鍵交換（JEP 527）、より小さいメモリフットプリントを実現するコンパクトなオブジェクトヘッダー（JEP 534）、さらに Java Flight Recorder の記録データが JVM 外に出る前に機密情報を削除する、JFR のプロセス内データ編集機能（JEP 536）などがあります。また、強化されたパターンマッチング、構造化並行処理、遅延定数のプレビューも継続されており、Vector API のインキュベーター版も含まれています。 Moonshot AI の Kimi K3 が Amazon Bedrock で一般提供を開始しました。Kimi K3 は、コーディングおよびナレッジワーク向けに Amazon Bedrock で利用できるようになりました。 。Moonshot AI によると、Kimi K3 は同社で最も高性能なモデルであり、2.8 兆パラメータ規模に到達した初のオープンモデルです。ネイティブなビジョン機能と 100 万トークンのコンテキストウィンドウを組み合わせており、大規模なリポジトリを対象とする長時間のコーディングセッション、複数ドキュメントの分析、拡張エージェント型ワークフローに適しています。Moonshot AI は、Kimi K2 と比較してスケーリング効率が約 2.5 倍向上したとしています。Kimi K3 は、Amazon Bedrock 上のオープンウェイトモデルとして初めて明示的なプロンプトキャッシュをサポートしており、コンテキストを複数のモデル呼び出しで再利用する際のレイテンシーと入力コストの削減に役立ちます。 AWS は利用開始時のエクスペリエンスを刷新しました 。新しいプロジェクトを開始するビルダー向けに、よりシンプルな新しい体験を発表しました。最初に設定作業をすべて完了するのではなく、適切なデフォルト設定ですぐに開始できます。Google、GitHub、Apple などの既存の ID プロバイダーを使用してサインアップでき、多くの新規ユーザーではクレジットカードも不要です。また、AWS Free Tier の一環として 100 ドル分の無料クレジットが提供されます。AWS は作業を「プロジェクト」単位で整理します。プロジェクトには AWS アカウントと共有設定が含まれ、セキュリティ管理も AWS 側で適用されます。チームメンバーを招待できます。IAM ユーザーを設定する必要はありません。月間利用上限額は 20 ドルから設定でき、後から高度な AWS 機能を追加費用なし、かつ移行作業なしで有効化できます。このエクスペリエンスは、徐々に新しいお客様にも展開されています。 新しい低コストで耐久性に優れた Amazon EC2 T8i インスタンスが一般提供を開始しました 。Amazon EC2 T8i インスタンスは、Intel Xeon Scalable プロセッサ（Granite Rapids）を搭載しており、EC2 インスタンスの中でも特に低コストな選択肢の1つです。前世代の T3 インスタンスと比較して、最大 30 %優れたコストパフォーマンスを提供します。マイクロサービス、低トラフィックの Web サイト、開発・テスト環境、小規模なデータベースなど、CPU 使用率が低～中程度のワークロード向けに設計されています。T8i インスタンスは、T3 と比較してコンピューティング性能が最大 70 %向上し、ネットワーク帯域幅が最大 1.25 倍、Amazon EBS 帯域幅が最大 2.4 倍向上しています。また、同じ CPU クレジットシステムを使用しているため、T3 からのアップグレードも容易です。 AWS Elastic Beanstalk に Cluster Mode が導入されました 。AWS Elastic Beanstalk Cluster Mode は、Amazon EKS を基盤とする共有インフラストラクチャ上で複数のアプリケーションを運用するチーム向けの、新しいフルマネージドオプションです。各アプリケーションを個別に運用するのではなく、単一の運用基盤上で複数のアプリケーションを実行できます。これにより、アプリケーションの数が増えるにつれて、アプリケーションあたりのコストを削減できます。Java、.NET、Python、Node.js、PHP、Ruby、Go のソースコードをアップロードでき、Elastic Beanstalk がコンテナ化を自動的に処理します。また、必要に応じて Cloud Native Buildpacks も利用できます。Cluster Mode には、自動ロールバックを備えた本番環境向けのデプロイ戦略、イベント駆動型のオートスケーリング、AWS Secrets Manager との統合、ネイティブな OpenTelemetry オブザーバビリティ、AI を活用したトラブルシューティングが含まれています。Standard Mode と Cluster Mode の環境は、同じアプリケーション内で並行して実行できるため、チームは環境を1つずつ段階的に移行できます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース お客様に役立つ可能性のある記事をさらにいくつかご紹介します。 AWS European Sovereign Cloud での構築 — 2つの新しい記事では、AWS European Sovereign Cloud 上での構築について紹介しています。これは、独自のコントロールプレーン、IAM、請求、コンソール、サービスエンドポイントを備え、独立したパーティションとして運用される欧州向けの独立したクラウドです。最初のリージョンはドイツ・ブランデンブルクに開設されます。最初の投稿では、アカウント構造とガバナンス、コードとしてのインフラストラクチャとしてのアイデンティティ、集中ロギング、データ保護、AWSパーティション全体で機能するパーティション対応ARNの構築など、 安全なランディングゾーンの設計について説明します 。2つ目は、AWS European Sovereign CloudのAmazon Bedrock次世代推論エンジンでGemma 4オープンウェイトモデルが一般公開されたことを発表しました 。データ保持やオペレーターアクセスゼロのモデルでは、推論は完全にeusc-de-east-1の範囲内にとどまります。 新しい AgentCore ランタイム：伸縮性に優れ、最適化され、一貫して高速な起動 — エージェントを実行するためのマネージドコンピューティングレイヤーである Amazon Bedrock AgentCore ランタイムの新バージョンを発表しました。新しいランタイムでは、セッション中のピーク時のメモリ量を保持し続けるのではなく、セッションがメモリを解放するとその分を回収します。そのため、料金はセッション全体を通じた実際の使用量に基づいて計算されます。また、コンテナイメージのサイズや同時実行数に関係なく、一貫したコールドスタート時間を実現します。これは、環境を一度準備してスナップショットを取得し、新しいインスタンスごとにそのスナップショットを復元することで実現しています。空のエコーエージェントを使ったテストでは、新しいランタイムは 200 MB のイメージから最大 2 GB までの約 2 秒で P75 コールドスタートを実現しました。これに対し、元のランタイムでは約 5.4 秒から 30 秒かかりました。 更新された AWS Well-Architected ストリーミングメディアレンズの紹介 — 動画ストリーミングワークロードのアーキテクチャのベストプラクティスを提供する改訂版ストリーミングメディアレンズを公開しました 。今回の改訂では、2021 年の初版から対象範囲が拡大され、5つのストリーミングシナリオをカバーしています。これには、Amazon IVS を使ったインタラクティブライブストリーミング、最大 25,000 人の同時視聴者に対応するリアルタイムストリーミング、低遅延ライブストリーミング、広告対応コンテンツの収益化、さらに強化されたビデオオンデマンドおよびライブストリーミングのガイダンスが含まれます。また、カーボンフットプリントの削減に重点を置いた新しいサステナビリティのベストプラクティス、拡張されたオブザーバビリティおよびインシデント対応フレームワーク、多層 DRM とフォレンジックウォーターマーキングを活用した高度なコンテンツ保護も追加されています。レンズホワイトペーパーとカスタムレンズがご利用いただけるようになりました。 AWS のブログ記事の詳細な一覧については、 AWS ブログ ページをご確認ください。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS re: Invent — AWS re: Invent が 11 月 30 日から 12 月 4 日までラスベガスに戻ります。2, 200 以上のセッション時間、ロケーション、講演者がライブ配信されます。AWS re: Invent の指定席は 10 月 6 日にオープンします。 今すぐ登録して 、指定席が開いたら、チョークトーク、ワークショップ、ビルダーズセッションに参加する準備をしてください。 AWS Summits – AWS Summits は、クラウドと AI をカバーする無料の実地イベントです。re: Inventが間近に迫った今、今年のサミットは終わりに近づいています。 最後のサミットはドバイ （9月30日）にドバイワールドトレードセンターで開催され、60以上のセッション、AWSビレッジ、ハンズオンワークショップが行われます。 AWS Community Days – コミュニティリーダーが企画および提供するコミュニティ主導のカンファレンス。今後のイベントには、 レバノン （9月26日）、 マレーシア、クアラルンプール （9月26日）、 フィリピンのセブ（9月26日）、フィリピンのダバオ （9月26日）、 英国のコムサム・マンチェスター（10月1日）、 イタリア、ローマ （10月2日）などがあります。 夏は正式に終わり、9 月を迎えましたが、私のいる場所では、まだ天候が季節の移り変わりに追いついていないようです。日中は今でも例年になく暖かく、本格的な秋が訪れる前の、最後の穏やかな午後なのではないかと思っています。この陽気が続いているうちに、できるだけ満喫しようと思います。9 月 28 日週もまた新しいニュースをお届けしますので、お楽しみに。 – Esra 原文は こちら です。

こんにちは！このたびタイミーは、9/11（金）開催のGo Conference 2026 にGoルドスポンサーとして協賛し、ブースを出展いたしました。 gocon.jp 素敵な場をつくってくださった運営のみなさま、そしてブースにお越しいただいたみなさま、ありがとうございました！ Closingでの発表によると、参加者は会場とオンライン合わせて700人を超えたそうです。その内、300人以上の方がタイミーのブースに立ち寄ってくださいました。 この記事では、タイミーのブース企画と、ブースでいただいた質問をご紹介します。執筆者はこちらの4名です。 Engineering Manager: 新谷（ @euglena1215 ） Backend Engineer: 成田（ @7riatsu ） Backend Engineer: 永田（ nagataaaas · GitHub ） DevEnable室: shihorin（ @shihorin_kjy ） 企画紹介 企画①タイミーでのGo活用紹介 株式会社タイミーは、「働きたい時間」と「働いてほしい時間」をマッチングするスキマバイトサービス「タイミー」を開発・運営しています。 バックエンドはRuby on Railsで主に開発していますが、認証基盤にはGoも活用しています。トータルプラットフォームを実現する構想の中で、Goの出番はこれから広がっていく可能性があります。 ブースでは、システム構成図やプロダクト戦略のイメージ図をご覧いただきながら、Go活用の現状と今後の可能性についてお話しました。 企画②Goの良いところを教えていただくアンケート ブースでは、アンケートへのご回答をタイミーでのお仕事に見立てた体験企画をご用意しました（実際の求人ではありません）。ご回答いただいたお礼にガチャを1回まわしていただき、ストレスボール、ぷくぷくシールなどのノベルティをお渡ししました。 アンケートの設問は「Goを選んでよかったこと、教えてください！」です。タイミーではこれからよりGoを活用していく可能性があります。そのため「Goエンジニアの先輩方からGoの良いところを教えていただきたい！」という意図でこの設問にしました。 結果はこちらです！ 元々用意していた選択肢に加えて、「バージョンUPしやすい」「Gopherがかわいい」という選択肢も途中で追加していただきました。 良いところ 票数 チームで読みやすく、保守しやすい 134 ビルド・デプロイがしやすい 94 並行処理を扱いやすい 69 ツールがそろっていて開発しやすい 49 性能を出しやすい、省リソース 43 Gopherがかわいい 35 まだ使っていない 11 バージョンUPしやすい 10 並行処理の扱いやすさや省リソースであることよりも、ビルド・デプロイの方がかなり票を集めていることに驚きました。 1エンジニアとしての言語の扱いやすさにとどまらず、プロダクトの一部として見たときの取り回しの良さが評価されているのかな？と考察しています。 企画③Reading List タイミーのプロダクト開発をもっと知りたい方向けに、「Reading List（おすすめ記事リスト）」をQRコードで掲示しました。その中から、特に反響のあった記事を紹介します。 タイミーの1,200万超ユーザーを支える認証基盤を Go と Ory Hydra で作っている話 バックエンド開発Handbookを届けるために ― AI時代の知の高速道路を敷く - Timee Product Team Blog プロダクト開発に関する記事の公開情報や登壇情報は、Xでも発信しています。ぜひご覧ください！ Timee Engineering / タイミーエンジニアリング 公式 (@TimeeDev) / X ブースで特にいただいた質問 + 回答 特に多くいただいた質問と、質問への回答をご紹介します。回答の中で出てくる用語は、以下の構成図でご確認ください。 再掲：ブースでお話ししながらご覧いただいた、システム構成図 Q1.「タイミーはGoを使っているのですか？Rubyの印象でした」 A.Goも使っています！基幹API（スポットワークのタイミー）はRubyで動いているのですが、ワーカー（toCユーザー）向けの認証基盤をGoで開発しています。 これまでバックエンドはRubyだけだったのですが、ここからバックエンドの言語のバリエーションを増やすことを前向きに検討していて、その中にGoが含まれています。 Q2.「タイミーの認証基盤はどういうもの？何のために作っている？」 A.複数事業展開を見据え、特定プロダクトに依存しない共通アカウント基盤が必要になったためです。 もともと認証機能は基幹 API（スポットワークのタイミー） に同居していましたが、それを最近切り出しました。スポットワークに隣接する事業を始めるために、同じアカウントでのログインや、データ連携ができるアカウント基盤が必要になったことがきっかけです。既存の認証機能は基幹APIの一部として実装されており、そのままでは共通の認証機能として利用できませんでした。そこで、独立したIdPとしてゼロから構築し、段階的に移行する判断をしました。 再掲：ブースでお話ししながらご覧いただいた、プロダクト戦略のイメージ図 Q3.「認証基盤だけGoなのはなぜ？なぜ認証基盤だけRails以外の技術選定をしたの？」 A.認証機能を既存のRailsアプリから独立したサービスとして切り出すにあたり、言語仕様がシンプルで、標準ライブラリや機能を絞った軽量なライブラリを組み合わせて必要な機能だけを実装しやすいGoを採用しました。型安全性や保守性を確保しやすく、長期運用する基盤との相性がよいことも理由の一つです。 また、OAuth2/OIDCに採用したOry HydraもGo製で、必要に応じて内部実装をコードリーディングで理解しやすいこともメリットでした。 Q4.「今後もGoを選定する予定はありますか？」 A.タイミーでは今後新規事業にも取り組んでいくことを検討しています。その際の技術選定の有力な選択肢としてGoを考えています。（検討・検証段階なので確定ではありません） 技術選定の参考にしたいという意図もあり、今回のブース企画を実施させていただきました。 Q5.「既存RailsアプリはGoにリプレイスするのですか？」 A.言葉通りのリプレイスは考えていません。 先述した認証基盤と同様、複数事業展開に伴い、いくつかの事業で同様の基盤が欲しくなることがあると思います。そういったユースケースが生まれた際に、基幹APIから共通基盤を切り出し移行する可能性は十分にあります。共通基盤の技術選定で、Goは候補のひとつになると考えています。その上で、Goが選ばれるのか、Rubyが選ばれるのか、はたまた別の言語が選ばれるのかはプロジェクト次第になりそうです。 Q6.「整合性チェッカーは何のためにあるのか？」 A.新たに構築した認証基盤(IdP)への移行途中である現在は、既存DBとIdP DBの双方へ書き込むダブルライト構成です。2つのDBでデータがずれる可能性があるため、整合性チェッカーが定期的に両DBを比較し、不整合を検知・通知しています。これは移行期間中の一時的な安全装置であり、読み書きをIdP DBへ完全に切り替え、ダブルライトを終了した後は廃止予定です。 おわりに ここまで読んでくださり、ありがとうございました！これからもGoコミュニティを盛り上げていけるよう、継続して関わっていけると嬉しいです。 最後になりますが、タイミーでは一緒にはたらく仲間を募集しています。ご興味をお持ちいただけましたら、ぜひカジュアル面談にお申し込みください！ プロダクト組織の概要や募集職種 シニアバックエンドエンジニア（プラットフォーム領域）採用情報 カジュアル面談のお申し込みはこちら