2026-04-30

生成AI各社の新モデル発表と、少し落ち着いて向き合いたい

はじめに

こんにちは。しおです。

最近に限った話ではないですが、生成AIの進化が著しいですね。毎週のように新しいモデルが発表されているので、情報量の多さに圧倒される今日この頃です。

そんな忙しい日々の中で、自分の中でちょっとした焦りのような感覚が生まれるようになりました。
というのも、各社発表のたびにメディアには「〇〇比で性能△△%向上」「推論能力が大幅改善」「業界最高水準のベンチマーク達成」といった言葉が並びます。ところが読み終わっても「で、結局このモデルは何がどう変わったの？」という疑問が残ることが、増えてきています。

原因のひとつは、発表文に出てくる専門用語を、なんとなく読み流していたことだと思います。
例えば、今回紹介する下記のような用語。

事後学習
有効コンテキスト
ベンチマーク飽和

今回は、そういった用語について自分なりに調べて整理してみました。定義だけでなく、発表を読むときに「ここを確認すると理解が深まる」というポイントも一緒にまとめています。

① 事後学習：モデルは事前学習だけで完成しない

事後学習とは、大量データで基礎的な能力を身につけたモデルに対して、指示追従・安全性・会話品質・ツール利用・特定タスクへの適応などを後から調整する工程です。

知識を新しく増やすというより、モデルの振る舞いを整える意味合いが強い言葉です。

出てきやすい表現

「事後学習で性能改善」「ポストトレーニングを強化」「指示追従性能が向上」「コーディングタスク向けに調整」といった表現で出てくることがあります。

事後学習で語られている「改善」は、知識の追加そのものではなく、回答の仕方や指示への従い方、安全性、ツールの使い方などの調整を指している場合が多いです。

落ち着いて読むための見方

事後学習という言葉が出てきたときは、まず「何のための調整なのか」を見ると理解しやすくなります。

たとえば、安全性を高めるための調整なのか、コーディング性能を高めるための調整なのか、エージェント的な作業をしやすくするための調整なのかで、意味合いは大きく変わります。

また、ある用途で改善したからといって、すべての用途で同じように良くなるとは限りません。安全性を重視した調整によって、回答が慎重になったり、特定のタスクでは期待より保守的な挙動になったりすることもあります。

② 有効コンテキスト：100万トークン入ることと、使えることは違う

有効コンテキストとは、モデルが受け付けられる最大トークン数ではなく、長い入力の中から必要な情報をどれだけ安定して見つけ、参照し、推論や回答に使えるかを指す見方です。

たとえば、AIMultiple の独自検証（Best LLMs for Extended Context Windows in 2026）では、22の主要AIモデルを対象に、広告上のコンテキストウィンドウのうち実際にどれだけ安定して機能するかを比較しています。同記事では、200kトークン対応をうたうモデルでも、実務的には130kトークン前後で不安定になる例があると説明されています。

このような検証はモデルや条件によって結果が変わるため絶対的な基準ではありませんが、「最大トークン数まで入る」ことと「その範囲を安定して使える」ことは別、という点を理解するうえでは参考になります。

また、長い出力を生成する場合も、構成維持・一貫性・重複の少なさ等の観点において、最後まで品質を保てるかは別途確認が必要です。

出てきやすい表現

「長文脈対応」「100万トークン対応」「大量のドキュメントを一括投入」「リポジトリ全体を理解」「長文でも精度が落ちにくい」といった表現で出てくることがあります。

こうした表現を見ると、長い資料をそのまま入れれば、モデルがすべて正しく読んでくれるように感じますが、最大コンテキスト長と、実務で安定して使える長さは必ずしも同じではないことに注意が必要です。

落ち着いて読むための見方

有効コンテキストで気をつけたいのは、「入力できる量」と「必要な情報を使える量」を混同しないことです。

長い入力を受け付けられること自体は便利です。ただ、入力が長くなるほど、モデルが必要な情報を見つけにくくなったり、回答の一貫性が落ちたり、料金やレイテンシが増えたりすることがあります。

また、単純な情報検索ではうまくいっても、複数の文書をまたいだ推論、契約書や議事録のような実務文書、コードベース全体の理解などでは、別の難しさが出てきます。

③ ベンチマーク飽和：高得点でも差が読みにくくなる理由

ベンチマーク飽和とは、多くの上位モデルが既存の評価セットで高得点を出すようになり、モデル間の実力差が見えにくくなる状態です。

例えば、代表的なベンチマークとその飽和の例を簡単にまとめたものが、下記の通りです。

評価のタイプ	代表例	見ているもの	飽和の例
知識・試験系	MMLU-Pro, AIME, MATH-500	知識や定型的な推論、数学・試験形式の問題	MMLUが上位モデルで飽和し、より難しいMMLU-Proのような評価が使われるようになっている。そのMMLU-Pro自体も、現在はトップモデルが90%前後に近づきはじめている
コード生成系	LiveCodeBench, BigCodeBench	関数実装、競技プログラミング、複雑な実装タスク	HumanEvalやMBPPでは差が見えにくくなり、LiveCodeBenchのような継続更新型の評価が使われるようになっている
難問・専門系	GPQA Diamond, MMMU	より難しい専門問題やマルチモーダル理解	GPQA Diamondでも、最新上位モデルのスコアが90%台に達しており、上位モデル間の差が縮まってきている
実務・エージェント系	SWE-bench Verified	実際のissue修正や業務成果物	上位モデルのスコアが急速に上昇しており、学習データへの汚染（contamination）の影響が指摘されはじめている。より汚染に強い評価への移行が進んでいる

このように、ベンチマーク飽和は単にスコアが高止まりするだけでなく、モデルの進化に合わせて「何で評価するか」という物差し自体が更新されていく現象でもあります。

なお、英語では saturation と綴るため、”サチる” と表現されることもあります。

出てきやすい表現

「既存ベンチマークが飽和」「MMLUやHumanEvalでは差が見えにくい」「より難しいベンチマークで比較」「実務ベンチマークで評価」「内部評価では改善」といった表現で出てくることがあります。

ここで大事なのは、個々のベンチマーク名をすべて覚えることではなく、その評価が何を測っていて、今でもモデル間の差が出る物差しなのかを見ることです。

たとえば、知識や試験形式の問題を見る評価、コード生成を見る評価、専門的な難問を見る評価、実際のissue修正や業務成果物に近い評価では、それぞれ見ている能力が違います。

落ち着いて読むための見方

ベンチマーク結果を見るときに気をつけたいのは、「最高水準」という言葉だけで、そのモデルがあらゆる用途で一番優れていると受け取らないことです。

上位モデル同士のスコアがかなり接近している評価では、数ポイントの差が実務上どれほど意味を持つのかは慎重に見る必要があります。

また、自分たちが使いたい用途と、そのベンチマークが測っている能力が近いかどうかも見る必要があります。数学の難問に強いことと、社内文書を安定して要約できることは、必ずしも同じ能力ではありません。

おわりに

ということで、新モデル発表が話題になる度に目にするのに、意外とちゃんと理解できていなかった3つの用語について、自分なりに整理してみました。

事後学習は、モデルの振る舞いを整える工程
有効コンテキストは、長い入力をどれだけ実際に使えるかの話
ベンチマーク飽和は、性能比較の読み方に関わる話

これらを意識しておくと、新情報を読むときの解像度が少し変わってくると思います。

新しいAIモデルの発表を受け取るときに大事なのは、どのモデルが一番すごいかを急いで決めることではなく、その「すごさ」がどの条件で成立しているのかを確認することです。そういう読み方ができると、次の発表が来たときにも少し落ち着いて向き合えるようになるのではないかと思っています。

今回、技術ブログでは6回目の執筆をさせていただきました。
1回目~5回目は、それぞれ下記のような記事を書いたので、お時間ある方はこちらもぜひ読んでいってください！

techblog.styleedge.co.jp techblog.styleedge.co.jp techblog.styleedge.co.jp techblog.styleedge.co.jp techblog.styleedge.co.jp

また、スタイル・エッジでは、一緒に働く仲間を絶賛大募集しています。
もし興味を持っていただけましたら、以下の採用サイトも一度覗いてみてください！

recruit.styleedge.co.jp

2026-03-31

念願のAWS Jamを自社開催しました！

AWS インフライベントエンジニアコミュニケーション

はじめに

こんにちは！スタイル・エッジでエンジニアをしているせっちゃんです！

前回のAWS Jamでは参加者だった私ですが、今回は「開催する側」に回りました。
この記事では、自社でAWS Jamを企画・運営した際の準備や当日の様子、参加者のリアクションを紹介します！

2回目のAWS Jamを開催した背景

前回、クラスメソッド株式会社様のサポートのもと社内メンバー6名でAWS Jamに参加しました。
実際のAWS環境で手を動かしながら課題を解く体験は座学とはまったく違い、参加者の満足度がとても高かったです。「またやりたい！」という声も多く上がっていました。

そこで、今回は自分たちの手で企画・運営してみることにしました。弊社ではAWS Skill Builderのチーム向けサブスクリプションを契約しており、Jamイベントの開催権限があります。前回の経験で当日の流れは把握できていたので、SREのpeipeiと2人で企画を進めていきました。

開催までの準備

メンバーの選定

今回は、バックエンドエンジニアとしてAWSを業務で実際に活用しているメンバーに声をかけました。「普段AWSに触れる機会はあるけれど、もっと深く理解したい」という層です。全体のバランスをとることを目的にインフラのメンバーにも声をかけました。

参加者はバックエンドエンジニア3名とインフラエンジニア1名の計4名。チーム編成は2人1組のペア × 2チームとし、経験や普段のコミュニケーションなどを考慮しチームを選定しました。

問題選定にはpeipeiにも協力してもらい、当日もサポート役として参加してもらいました。

一番苦労した「問題選定」

準備で一番大変だったのが、問題（チャレンジ）の選定です。

AWS Jamでは、Skill Builderの管理画面からチャレンジを選んでイベントを構成します。チャレンジにはそれぞれ難易度やカテゴリがあり、どれを選ぶかで参加者の体験が大きく変わります。

選定で意識したのは、業務で実際に使っているAWSサービスに関連するチャレンジを選ぶことです。せっかく時間を使って取り組むなら、普段の業務に活きるものにしたいと考え以下のリソースを対象としました。

EC2 (Amazon Elastic Compute Cloud)
Lambda (AWS Lambda)
RDS (Amazon Relational Database Service)
S3 (Amazon Simple Storage Service)
WAF (AWS Web Application Firewall)

最終的に、Easy 3問 + Medium 3問の計6問を選びました。「これは難しすぎるかも…」「でもこの領域は経験してほしい」と何度もミーティングを重ねて決めた構成です。

事前の周知

当日スムーズに進められるよう、参加者にはあらかじめAWS Jamの操作方法やルールを共有しておきました。加えて、今回出題するチャレンジがどのあたりの領域に関するものかも事前に伝えています。予備知識がゼロの状態でいきなり本番に臨むより、事前学習→本番→復習のサイクルに期待をしました。

当日の様子

タイムスケジュール

開催日は2026年2月2日（月）、東京本社オフィスです。

時間	内容
15分	説明（Jamの進め方、チャレンジの紹介など）
100分	AWS Jam 本番（100分）
15分	解説・振り返り

かなりコンパクトですが、6問に取り組むには十分な時間です。（と思っていたのですが、実際はあっという間でした）

開催者としての立ち回り

私とpeipeiは今回Jamには参加せず、企画・運営に専念しました。

当日意識したのは、「楽しく、学ぶ」ことにフォーカスできる雰囲気づくりです。スコアボードは表示されるので自然と競争心は生まれますが、あくまで目的は「手を動かして学ぶこと」。冒頭の説明でその点をしっかり伝えました。

参加者が詰まっている様子が見えたときは、ヒント機能の案内をしたり、一緒に画面を見ながら考えたり。参加者が問題に集中できる環境を提供することを意識しました。

解説を自分で作ってみて

Jam終了後の解説も私が担当しました。正直、ここが一番勉強になりました。人に説明するには課題を深く理解する必要があるので、チャレンジの背景にあるAWSの設計思想やベストプラクティスまで調べることになります。準備していた自分が一番知識を深めた気がします。

参加者からのリアクション

Jam終了後、Googleフォームでアンケートを取りました。いくつかの設問と結果を紹介します。

AWS Jamイベント全体の満足度を教えてください

満足度の高いイベントとなりました！

内容の難易度はいかがでしたか？

やや難しいを目標に問題を選定していため、想定通りの回答でした！次回開催の際にも参考にできる結果となりました。

AWSアーキテクチャ設計に対する理解度は深まりましたか？

開催当日だけでなく事前学習の推奨や、フォローアップの体制を強化し、理解度向上に努めます！

今後もAWS Jamイベントがあれば参加したいですか？

とても嬉しい結果となりました。

開催者として印象的だったのは、参加者がチャレンジに取り組んでいる最中の表情です。ペアで相談しながら設定を変えて、検証して、課題をクリアした瞬間に「わかった！」という顔をしてくれる。こういう場面を間近で見られるのは開催者の特権だと思います。

次回に向けて

2回目の開催を終えて、次に向けたアイデアがいくつか出ています。

参加者をもっと増やしたいです。今回は4名でしたが、バックエンドやインフラに限らず、いろんな職種のメンバーが参加できる回も企画してみたいと思っています。

テーマを絞った回もやってみたいです。セキュリティ特化回や、生成AI関連のチャレンジだけを集めた回など、参加者の興味や業務に合わせてカスタマイズできるのは自社開催の強みです。

そして定期開催にしていきたい。1回きりのイベントで終わらせず、社内に「学びの場」として定着させること。イベント感を出す工夫（軽食や優勝チームへのちょっとしたプレゼントなど）も取り入れていきたいと考えています。

おわりに

「参加する側」から「開催する側」に回ってみて、準備は大変ですがそれ以上に得るものが大きいと実感しました。問題選定でAWS知識の棚卸しができたり、解説作成で理解が深まったり、開催側ならではの学びがたくさんあります。

前回参加から今回のJam開催まで、「学ぶ → 実践する → 届ける」のサイクルを1周できました。このサイクルをこれからも回し続けて、社内のAWS力を底上げしていきたいです！

最後までお読みいただき、ありがとうございました！

一緒に働く仲間を募集しています！

スタイル・エッジでは、AWS Jamのようなイベントを一緒に企画したり参加したりしてくれる仲間を募集中です。「手を動かしながら学ぶ」文化に興味がある方、ぜひ採用サイトを覗いてみてください！

recruit.styleedge.co.jp

2026-02-05

SRE Kaigi 2026現地参加！熱量の高い現場から持ち帰った学び

SRE イベント GC AWS

はじめに

こんにちは！スタイル・エッジでSREエンジニアをしているpeipeiです。

今回は SRE Kaigi 2026に参加してきました！
SRE Kaigiは、SREに関わる人たちが集まり、現場の知見や悩みを共有するカンファレンスです。参加者同士の交流を通じて、新たな発見やインスピレーションを得られる場として注目されています。

筆者自身、SRE Kaigi 2025のアーカイブ動画をすべて視聴するほど、以前から気になっていたイベントでした。
「この熱気を会場で味わいたい！他社SREの生の声が聞きたい！」と思い、上司に相談したところ快く背中を押してもらい、福岡から東京へ出張し、SREに興味を持っているエンジニアのせっちゃんと2名で現地参加してきました。

この記事では、会場の雰囲気や印象に残ったセッション、そして今後スタイル・エッジのSREとして取り組んでいきたいことをまとめます。

参加の目的

今回の参加目的はいくつかありますが、なかでも一番大きいのは、「他社の苦悩や失敗談のリアルを聞き、同じ状況で悩んだときの羅針盤にすること」です。

弊社では昨年SREチームを立ち上げ、システムの信頼性や開発生産性を見直す活動を進めています。0→1のフェーズは想像以上に難しく、特に「SREを維持・継続し、文化として根付かせること」に苦戦しています。

そんなときに他社のSRE事例を見ると、驚くほど同じところで悩んでいることが分かり、「自分だけじゃないんだ」と励まされることがあります。

SRE Kaigiのようなイベントでは、表に出にくい“裏側のリアル”に触れられる機会も多く、思わず何度もうなずいてしまう場面があります。そういったリアルから学びを持ち帰り、今後の取り組みに活かしていきたいと思っています。

会場の様子・企業ブース

開会式の時点でたくさんの方がいらっしゃって、「私と同じように楽しみにしていた方がこんなにいるんだな」と感じました。実際にセッションが始まった際も、PCを持ってメモをしている方や、セッション後に登壇者へ質問しに行っている方など、積極的に情報を取りにいく姿も印象的でした。

また、企業ブースも各社が工夫を凝らしており、見応えがありました。 SREが抱える課題と、それを解決するためのアクションをポストイットに書いて貼れるようにして意見を募ったり、システムのアーキテクチャ図を用意して抱えている課題について話したりするなど、各社さまざまな工夫が見られました。

中でも株式会社MIXI様の「SRE成熟度チェック」は、特に面白い取り組みだと思いました。

やはりSREのスタートラインとも言われるSLOやエラーバジェットの運用は、一番難しいところだよなあ…と改めて感じました。また、「取組中」にシールを貼った方は、取り組み自体は進めているものの、さまざまな課題感を抱えているのだろうな、と想像しました。

セッションレポート

私が拝聴したセッションの中で、特に印象に残ったものを3つ紹介します。

生成AI時代にこそ求められるSRE

基本情報

登壇企業：アマゾンウェブサービスジャパン合同会社
登壇者：山口能迪氏

speakerdeck.com

概要

生成AIの普及により、もはや「AIを業務で使うべきか」を議論するフェーズは終わり、多くの方が業務でAIを利用する時代になりました。生成AIはソフトウェア開発の生産性を爆発的に高める一方で、システムの不安定化や変更失敗率の増加といったリスクも同時に押し上げるといいます。

SREの責務は、この生産性向上を「カオス」にせず、持続可能なユーザー価値へと変換することにあります。本セッションでは、そのための戦略として「コンテキスト」と「ガードレール」という2つの観点を軸に掘り下げていました。

主なポイント

1. AIは組織の能力を増幅する「アンプ」である
AIは、組織の長所だけでなく課題も含めて増幅させる「アンプ（増幅器）」のような存在だ。開発速度は上がる一方で、もともと課題を抱える組織では、システムの不安定さや失敗率まで増幅される。だからこそ、SREによる信頼性の土台づくりは、これまで以上に重要になっている。

2. AIが正しく動作するための「コンテキスト」を補強する
AIは一般的な知識を持っていても、特定のシステム固有の情報までは把握していない。AIがより正確にデバッグや分析を行うには、システム固有のテレメトリーやアーキテクチャ図など、静的・動的両方の情報を「コンテキスト」として提供する必要がある。

3. AIの失敗を予防・回復する「ガードレール」を強化する
AIの不確実な出力や、爆発的に増えるコード生成量に対処するための「保険」を整える。ハルシネーションや脆弱性の混入を防ぐには、常に同じ結果を再現できるビルドプロセス、高度な自動テスト、ポリシーによる統制といった仕組みが欠かせない。

SREが提供すべき「コンテキスト」と「ガードレール」の分類

大分類	中分類	具体的な内容・プラクティス
コンテキスト (AIの精度を高める下地)	1. オブザーバビリティ	高次元なイベントや構造化ログを活用し、AIがシステム状況を科学的に判断するための文脈を提供する。
	2. Everything as Code (XaC)	IaCやドキュメントなど、あらゆる情報をコード化して管理することで、人間とAIの両方が理解・追跡可能にする。
	3. ポストモーテム	AIと共に障害のタイムラインや根本原因を蓄積し、AIが次なるデバッグを行う際の重要な知識源（コンテキスト）とする。
ガードレール (AIの失敗を制御する保険)	1. 密封ビルドとセキュリティ	常に同じ結果を再現するビルドプロセスを構築し、SBOMの活用等で不適切なライブラリの混入や脆弱性を防ぐ。
	2. 発展的なテスト手法	ファジングやミューテーションテストをCI/CDに組み込み、AIが生成した大量のコードの品質を自動で担保する。
	3. Policy as Codeによる統制	OPA等のツールを用いて、AIが生成した構成が組織のポリシーに違反していないかを自動で検証する。
	4. SLOに基づいたリリース	カナリアリリース等を活用し、SLOベースで自動ロールバックを行うことで、AIによる変更の影響を最小化する。
	5. SRE文化	AIの提案に異議を唱えられる「心理的安全性」を拡張し、自動化バイアス（AIを鵜呑みにする傾向）を排除する。

得られた学び

本セッションを通じて、SREが重視してきたオブザーバビリティやSLOは、今や「AIが正確に判断を下すための必須のデータセット」へと進化していることを学びました。特に印象的だったのは、ポストモーテムを「AIも読むもの」と再定義し、組織の教訓をAIの知能に循環させるという視点です。

AIを正しく導くためにSREを実践し、「コンテキスト」と「ガードレール」を手に入れるという姿勢がこれからのエンジニアに求められる指針だと感じました。

ゼロからはじめるSRE：一人運用から複数プロダクト・SREチーム立ち上げまでの軌跡

基本情報

登壇企業：株式会社TalentX
登壇者：籔下直哉氏

speakerdeck.com

概要

本セッションでは、一人でのインフラ運用からSREチームを立ち上げ、複数プロダクトを支える共通基盤を構築するまでの道のりが語られていました。

創業期のレガシーな環境からAWSへの完全移管、そして属人化の脱却を目指した組織的なSRE活動への進化が描かれていました。事業成長と技術負債の解消というジレンマに直面しながら、「現実的なスピード優先」と「理想の追求」を使い分けた意思決定のプロセスが具体的に語られています。最終的には、モニタリング・コスト・セキュリティ・IaCの4領域における体系的な改善へと至っています。

主なポイント

1. レガシー脱却と将来を見据えた基盤刷新
採用の壁やサービス停止リスクとなっていたレガシーな構成を見直し、将来のSRE採用やマルチプロダクト展開を見据えたモダンなAWS基盤（EKS/ECSなど）へ刷新した。

2. SREを「承認のボトルネック」から「ガードレール」へ
手作業中心の運用から脱却し、Terraformのモジュール化に加えて、AIや静的解析を活用した。開発者がSREの承認待ちで止まらず、安全かつ迅速に自走できる体制を整えた。

3. 経営と連動した戦略的なSRE活動
SLI/SLOを軸にした開発チームとの文化醸成、経営判断に基づくコスト最適化、成熟度モデルを用いた計画的なセキュリティ強化などを推進した。技術面に閉じず、組織・経営面も含めた最適化に取り組んだ。

AWS移管後に行われた主な運用改善

改善領域	AWS移管直後の課題	行った施策	実現した効果
モニタリングとSLI/SLO	APIの5xxエラー率を可視化しているだけで、形骸化していた。	Slack通知の運用や月次会議を通じ、開発チームと状況を共有する文化を醸成した。	開発チームが自らSLOを意識し、異常時に自発的なアクションを起こせるようになった。
インフラコスト管理	実績ベースの感覚的な予算策定となっていた。	AWS Cost Explorerによる異常検知の導入、RI/Savings Plansの適用条件を経営層と戦略的に決定した。	経営と連動した「計画的・戦略的なコスト最適化」が可能になった。
セキュリティ強化	顧客対応や外部診断に基づく、受動的なアップデートが中心だった。	AWSセキュリティ成熟度モデルを採用。半期ごとのKPI設定や、WAFマネージドルールによる標準化を行った。	組織としての現在地を客観的に把握し、計画的なセキュリティ強化を推進できるようになった。
IaC周りの整備(Terraform)	手作業が多く、再現性やコード品質の維持に課題があった。	コードをモジュール化し、GitHub CopilotやTFLintを活用したデプロイパイプラインを自動化した。	開発速度とガバナンスを両立する「ガードレール」が構築された。

得られた学び

スモールスタートで始め、改善を繰り返しながら組織を変えていく姿が非常に印象的でした。自社でも取り組めている部分と、これからの部分があるため、トライアンドエラーを重ねながら文化を育てていく必要性を改めて感じました。

特に、SLI/SLOなどの数値を出すだけでなく、「開発チームが自ら意識し、アクションにつなげられる文化」を作っている点が印象的でした。周囲を巻き込みながら、自然と根付く状態を目指していきたいです。

また、SREには「技術負債を放置するリスク」と「理想を追いすぎてオーバーエンジニアリングになるリスク」が常に付きまとうと感じました。組織のフェーズに応じて「今やるべきこと」を優先順位付けし、投資対効果を意識して戦略的に実行することが重要だと感じました。

Embedded SREの終わりを設計する〜「なんとなく」から計画的な自立支援へ〜

基本情報

登壇企業：Sansan株式会社
登壇者：鷹箸孝典氏

speakerdeck.com

概要

SREのミッションを「サービス立ち上げの速度を高め、運用コストを削減すること」と定義した際、特定の開発チームに長期間「なんとなく」関わり続けることは、SREがそのチームに固定され、知見が全社に広がらないという課題を生みます。

本セッションでは、SREが組織のボトルネックになるのを防ぐため、開発者の自立をゴールとした段階的な支援体制の設計について語られました。特に、知識移転を定量化する「SRE Knowledge Transfer Matrix」を導入し、データに基づいた支援と「Exit（撤退）」の判断を行っている点が特徴です。一箇所での「終わり」を組織全体の「始まり」につなげる、持続可能なSREモデルの構築を目指されている姿が印象的でした。

主なポイント

1. 「なんとなく」の関係からの脱却とExitの合意
明確な終わりのない支援はSREのリソースを枯渇させ、組織的なスケーラビリティを阻害する。そのため、開発チームと「自分たちが不要になること」を共通ゴールとして合意した。これにより、単なる「サポートする側・される側」という関係から、自立を目指す対等なパートナーへと再定義されている。

2. 定量的な知識移転の可視化（Knowledge Transfer Matrix）
主観的な「自信度」と客観的な「経験」を組み合わせた「2軸評価」により、知識移転の状態を数値化している。これにより、個人の成長だけでなく、チーム全体の冗長性を測定できるようになった。客観的なデータに基づいて「SREが離脱しても問題ないか」を判断できる仕組みが構築されている。

3. 「成功＝終焉」というパラドックスの追求
Embedded SREの本質的な価値は、「自らの仕事をなくすために一生懸命働くこと」にあります。一つのチームで支援を終える（Exitする）ことで、SREは次の課題を抱えるチームへ異動でき、自立した開発者が別のチームへ異動することで知識が組織全体へ波及していくという、持続可能なサイクルを生み出しています。

得られた学び

「測定できないものは改善できない」という原則に基づき、知識移転を可視化したことで、具体的な対話と改善アクションが可能になっていた点が大きな学びでした。

また、SREがチームを抜けることを、開発者にとって単なる「仕事の増加」と捉えるのではなく、「自らの守備範囲を広げ、自立するための前向きなステップ」であるというマインドセットを共有できていたことが印象的です。

さらに、チーム内の誰が教えられるレベルになっているかを分析して、チーム全体の能力カバレッジを100%に近づけることで、特定の個人に依存しない「チームとしての強さ（冗長性）」が確保されるという視点は、組織づくりにおいて重要な気づきとなりました。

全体の感想

今回は、弊社としても個人としても初のSRE Kaigiへの参加となりました。会場はSREに興味を持つ方ばかりで、とても熱量の高いイベントだと感じました。少し驚いたのは、現在SREではない方や、自社にSRE組織がない方も多く参加されていたことです。SREが特定の職種だけのものではなく、より広く必要とされている領域になっているのだと感じました。

また、「月間数億レコードのアクセスログ基盤を無停止・低コストでAWS移行せよ！アプリケーションエンジニアのSREチャレンジ💪」という宮村紅葉氏のセッションで、
「SREでない人のSRE活動にも大きな価値がある」
「SREは役職ではなく魂」
という言葉には痺れました。

SREだからSREをやるのではなく、クライアントや自社の開発メンバーのために動いた結果が、いわゆるSRE活動になるのだと思います。そういったスタンスで、できることからスモールスタートで改善を積み重ね、組織として文化を育てていきたいと感じました。

私は今後もSRE Kaigiに参加し続けたいと思います。社内のメンバーもどんどん巻き込み、もっと多くの方と一緒に現地で学びたいです。そしていつかは、弊社からもプロポーザルが出せるようになれば嬉しいなと思います。

おわりに

最後まで読んでいただきありがとうございました！

スタイル・エッジでは、一緒にSRE活動を進めてくださる仲間を絶賛大募集しています。

もし興味を持っていただけましたら、以下の採用サイトも一度覗いてみてください！

recruit.styleedge.co.jp

最後におまけ

屋台という形で、おにぎりや唐揚げ、たこ焼きなどが無料で提供されていました。アルコールを含むドリンクもあり、11時の時点で呑んでいる方もいました。

ノベルティもたくさんいただきました。個人的には、株式会社SmartHR様からいただいたDockerコンテナのアクリルキーホルダーが一番ツボでした。

2026-01-30

連携仕様が少ない外部サービスと自社サービスを、なんとかしていい感じに連携したい。

エンジニアコミュニケーションマネジメント

はじめに

こんにちは、しおです。最近は直接的な開発からは離れて、PM を主にやっています。

今日は、「ビジネス部門の現場にて先行導入された外部サービスがあり、"このサービス内の情報を自社開発の CRM に転記する" という業務の効率化をしたい、という要望が来た。」という状況についての対応策を考えてみたいと思います。

というのも、こういった展開は事業系の会社ではあるあるなのではないかと勝手に思っていまして、私も最近 PM として同じような状況になったことがあるので、その時の思考整理も兼ねて、具体的にどのような連携パターン（プラン）があり得るのか、それぞれのメリット・デメリットをまとめてみました。

※ なお、本記事は実際の事例をベースにしていますが、ブログ用に大幅に構成を変更したフィクションです。記事内で題材としている外部サービスも架空の設定であり、実在する特定の企業・サービスとは一切関係ありません。

はじめに
想定シナリオ
王道パターン：Webhook 利用
Webhook 以外の連携方式を色々考えてみた
おわりに

想定シナリオ

今回の想定シナリオは、下記の通りです。

ビジネス部門の施策で、マーケティング施策用の外部ツール（以下、"外部サービス" と呼称）を利用することになった。
実証施策のため、いち早いサービス導入とフィードバックが必要になり、現場で先行導入開始。
実証施策の流れで、外部サービスの利用が現場に定着する。
外部サービスから自社の CRM（以下、"CRM" と呼称）には 手動で必要な情報をコピペして転記する という運用が現場に定着する。
ゆくゆくは CRM に外部サービスの情報を効率的に同期したいと現場は考えている。

また、連携対象の外部サービスの想定仕様は下記の通りと仮定します。
なお、この仕様が今回の悩みどころです。

外部サービスの概要：顧客へのアプローチやアクション履歴を管理するマーケティングツール。
外部連携の手段：Webhook と API が用意されている。
Webhook の仕様
- イベント発火タイミング：顧客による何らかのアクション発生時（リアルタイム）
- 課題：ペイロードに、CRM連携に必要な「顧客メールアドレス」等の個人情報が含まれていない。
  - 含まれているのは event_id と external_user_id（外部サービス内のID）のみ。
  - つまり、Webhook だけでは「誰がアクションしたのか」が特定できず、事前にIDのマッピングテーブル等を用意しない限り、これ単体での CRM 自動転記は困難。
API の仕様
- 提供機能：アクション履歴やユーザー情報の取得（GET /v1/users GET /v1/activities 等）
- 課題：検索条件（フィルタリングパラメータ）が貧弱。
  - 利用できるパラメータはページネーション用の page と limit のみ。
  - 「更新日時」や「登録日」での絞り込みができない。
  - つまり、「昨日アクションがあったデータ」だけをサーバーサイドで絞り込む術がなく、リストを総当たりで取得して自社側でループ処理・判定をする必要がある。

このように、自社の CRM に外部のサービスを連携したいという要望がありつつも、肝心の外部サービスの連携仕様が少ない場合に、どのように対応していくか、ということを考えていこうと思います。

王道パターン：Webhook 利用

まず最初に思いつくのが、外部サービス側で提供されている Webhook を利用したリアルタイム連携でしょうか。

正直、これですんなりいけるのがシンプルなので一番嬉しいです。
ただ、今回のシナリオのように肝心の Webhook 経由で連携される情報に現場で欲しい情報が含まれていなかったり、連携のタイミングや連携条件（フィルタリング等）に不都合があったりすると、どうでしょうか。

今回、私たちが悩まされたのは、まさにそのような状況でした。

Webhook 以外の連携方式を色々考えてみた

ということで、次は外部サービス側の Webhook 等の連携仕様（「情報」「条件」「タイミング」）に左右されないプランをいくつか考えてみようと思います。

プランA：割り切って、自動連携できる範囲のメリットは享受して、残りは手動で対応する

いきなり割り切りプランを提示してしまい大変恐縮なのですが、「少なくとも自動連携できているだけでもありがたい」「提供されていないものは仕方がない」ということで、自動化できる部分は自動化して、それ以外は諦めて手動で対応、もしくは連携を諦めるというプランです。

これを、先述の悩ましい三要素の軸で評価してみましょう。

悩ましい要素	制約への対応状況
情報	❌ 不足（手動補完）
条件	❌ 選べない
タイミング	⭕️ 自動（リアルタイム）

情報：外部サービス側で提供されている情報（ID等）のみを自動で連携し、残りの情報は捨てる。もしくは後から手動で転記する。
条件：外部サービス側で提供されている条件（フィルタリングできず、全件飛んでくる）に従って自動で連携し、自社側で情報を取捨選択する。
タイミング：外部サービス側で提供されているタイミング（リアルタイム）に従って自動で連携する。

外部サービスの仕様で実現できる範囲の自動化をするという省エネプランです。
省エネということで、システムの構築スピードが速いというメリットはありつつ、そうは言っても切り捨てられない情報については引き続き手動での転記をするなどの対応が必要で、現場側の負担が大きい形となってしまうため、出来れば避けたいところです。

プランB：Pull方式（CRM から外部サービス側の API をコール）にしてタイミングを握る

次は、Webhook ではなく API を利用するプランです。CRM 側から外部サービスの API をコールして、必要な情報を取得します。

悩ましい要素	制約への対応状況
情報	🔺 全件取得でカバー
条件	🔺 全件取得でカバー
タイミング	⭕️ 自社で制御可能

リアルタイム性が失われる可能性がある一方で、連携のタイミングについては完全にこちらでコントロールできるというメリットがあります。
一方で、今回のように検索条件が乏しい API の場合、「毎回全件取得して、自社側で差分を判定する」といったような実装が必要になり、データ量が増えると API のレートリミットに抵触するリスクや、差分検知ロジックの複雑化（冪等性の担保など）により実装工数が膨れ上がる懸念があります。

プランC：Webhook + API のハイブリッド

プランAの「タイミングの良さ」と、プランBの「情報の網羅性」を組み合わせた、いいとこ取りを目指すプランです。

処理の流れは以下のようになります。

Webhook 受信：外部サービスから通知を受け取る。
API コール：受け取った external_user_id などの情報をキーにして、外部サービスの API（GET /v1/users/{id} 等）を叩きに行く。
データ保存：API から返ってきた情報を CRM に保存する。

悩ましい要素	制約への対応状況
情報	⭕️ APIで完全取得（※ これも API の仕様次第ではあるが）
条件	🔺 Webhook で絞れなくても、API コール時にフィルタリング
タイミング	⭕️ ほぼリアルタイム

パッと見では、これが今回のケースにおける「正解」に最も近いように見えます。

ただし、これにも「API のレートリミット（回数制限）」と「実装コスト」という懸念点は存在します。
もし外部サービス側で一括更新などが行われ、Webhook が短時間に大量（例えば数千件）に飛んできた場合、その回数分だけ愚直に API を叩くと、外部サービスの API レートリミットにあっという間に抵触してしまいます。

これを防ぐためには、自社側でジョブキュー等の仕組みを導入し、API コールの流量を制御する実装が必要になります。
プランAやBに比べると、システム構成がリッチになる分、構築コストが高くなってしまうのが悩みどころです。

プランD：ブラウザ拡張／ブックマークレットで「転記しやすい形」に整える（半自動化）

Webhook も API も満足に利用できない、あるいはプランCのようなリッチな実装をする工数が割けない状況で、現場では「外部サービスの画面上に表示されている情報を CRM に転記する」というような運用をしている場合に有効な（⚠ただし飛び道具的な）プランです。

具体的には、下記のような流れを想定しています。

画面上の情報を、特定フォーマットでクリップボードにコピーするブラウザ拡張機能やブックマークレットを作成し、現場に配布
自社 CRM 側で、上記フォーマットでのデータインポート機能を開発
上記機能を用いて、半手動でのデータ転記を実現

悩ましい要素	制約への対応状況
情報	⭕️ 画面通り取得可
条件	⭕️ 人が目で見て選択
タイミング	🔺 人の手による

外部サービス側が変えられない（定数）のであれば、変数である自社サービス側を変えてしまおう、という発想です。一見では既存運用とほぼ変わらないように見えますが、「データ転記という作業の手間を解消」することにフォーカスしています。

「飛び道具的」と表現した通り、やや強引感は否めないとも思いつつも、転記する情報が多い場合などは意外とこれだけでも効果が大きい場合もあると思います。
ただし、外部サービスの画面仕様（DOM構造）が変わると即座に使えなくなるため、メンテナンスコストは考慮する必要がありますし、そもそものブラウザ拡張やブックマークレットの配布方法についても考慮が必要です。
いずれにせよ緊急回避的で、常用するプランではなさそうですね。

おわりに

今回、様々な連携パターン（プランA〜D）を検討してきましたが、痛感したのは「外部連携の難易度は、外部サービスがどのようなインターフェースを用意してくれているかに大きく左右される」という事実です。

理想を言えば、導入前にビジネス部門と開発部門で連携要件と運用をすり合わせ、仕様を踏まえてサービス選定まで行えるのが最も安全です。
とはいえ、スピード重視で先に運用が走ることは現実に起こり得ます。そうなると、「いっそのこと、現場の運用に完全にフィットするシステムを内製で開発してしまえば、連携の悩みもなくなり幸せなのでは」と頭をよぎることもあります。

しかし、マーケティングや営業支援といった特定領域における外部サービスベンダーの知見や機能の充実度、そして何より導入すればすぐに使えるというスピード感は、自社開発では簡単には真似できません。「餅は餅屋」という言葉がある通り、優れた外部サービスを使い倒すことはビジネスを加速させる上で不可欠です。

そう考えると、私たちが直面した連携の難しさは、外部サービスの良し悪しというよりも、「汎用的に作られた優れたサービス」と「自社独自の泥臭い業務フロー」の間に必然的に生じるギャップ なのかもしれません。

だからこそ、私たちエンジニアには そのギャップをどう技術で埋めるか が問われているのだと考えます。

完璧な自動化を前提にせず、どの要素が制約になっているかを見極めること。
API がリッチならプランCで堅牢に、スピード優先ならプランAでまずは動かす、どうしても仕様が噛み合わないならプランDで運用をカバー...。

すべてを自社で作るのでもなく、仕様だからと諦めるのでもなく、手持ちのカードの中で外部サービスの価値を最大限に引き出しつつ、現場の負担を減らす最適な構成を考える。それがエンジニアとしての醍醐味であり、外部サービスとうまく共存していくためのポイントなのだと改めて感じました。

現場の運用を止めずに、最短距離で負担を減らし、段階的に最適に近づけるような設計を今後も推し進めていきたいと考えています！

今回、技術ブログでは5回目の執筆をさせていただきました。
1回目~4回目は、それぞれ下記のような記事を書いたので、お時間ある方はこちらもぜひ読んでいってください！

techblog.styleedge.co.jp techblog.styleedge.co.jp techblog.styleedge.co.jp techblog.styleedge.co.jp

recruit.styleedge.co.jp

2025-12-29

社内データを意思決定の「資産」へ。Analytics Engineerとして挑むデータ基盤の裏側と技術スタック

データベース BI GC Google

2025-11-30

社内向けウェブサイト制作フレームワークからPHPからAstroへ乗り換えた話

JavaScript WEB

2025-10-31

入社1年目でAI-OCR開発！？新卒が挑んだ“ゼロからの挑戦”

新人エンジニア AI Gemini Google GAS

はじめに

こんにちは、スタイル・エッジの みかきち です！今年から新卒1年目として入社しました！！

私は普段、自社やクライアントのバックオフィス業務を支援するため、主にGoogle Workspaceの各種サービスであるAppSheetやGAS（Google Apps Script）を用いてアプリケーションを開発しています。
まだまだ学ぶことばかりですが、日々の業務や技術を通して得た気づきや学びを、このブログで少しずつ発信していけたらと思います。

この記事では、フォーマットがバラバラな書類の転記作業といった課題を解決するために開発した「AI-OCRシステム」の実例をご紹介します。
Google Workspaceのサービス（Googleフォーム, GAS）とGemini APIを組み合わせて、AIコーディング（AIによるコーディング支援）の力も借りながら、普段使っているツールだけでここまで業務を自動化できる、という方法をぜひご覧ください！

1. 課題：外注せざるを得なかった「手入力」の悩み

AI-OCRシステムを開発するきっかけとなったのは、とあるクライアント様から共有された一つの課題でした。

そこでは、フォーマットの異なる大量の書類（デジタルと手書きが混在）を、特定フォーマットに入力し直すという作業が日々発生していました。
この作業は非常に手間がかかるため、これまでは外部の業者に委託していたということです。

しかし、それには2つの大きな問題点がありました。

金銭的コスト：外注には費用がかかり続けます。
時間的コスト：外注し、作業が完了して戻ってくるまでにタイムラグが発生し、業務のスピードを妨げていました。

この非効率な「手入力」と「外注のタイムラグ」を解消することがミッションでした。

2. 解決策：Google Workspaceで作る「AI-OCR」の全体像

手入力と外注の非効率を解消するため、Gemini APIとGoogle Workspaceの各種サービスを連携させた、内製AI-OCRシステムを構築しました。
システムの全体像は非常にシンプルです。

処理フロー

アップロード：ユーザーがGoogleフォームに、データ化したいPDF書類をアップロードします。
起動：フォーム送信をトリガーにGASが起動します。
読取・整形： GASがGemini APIを呼び出し、PDFデータを読み取らせ、必要な情報を抽出・整形させます。
出力：整形されたデータが、自動でGoogleスプレッドシートに出力されます。
通知：すべての処理が完了したら、チャットツールでユーザーに通知します。

一見、簡単な仕組みに見えますが、このシステムを高精度かつ安定的に動作させるためには、2つの大きな課題を乗り越える必要がありました。

3. 実装ハイライト：立ちはだかった2つの技術課題

このシステムを安定稼働させる上で、私たちが直面した課題は大きく2つあります。

AIの精度問題：書類の「揺らぎ」にどう対応し、精度を安定させるか
GASの制約問題： 6分でタイムアウトする実行時間をどう乗り越えるか

それぞれの課題をどう解決したのか、具体的な実装ポイントをご紹介します。

ポイント①：高精度を実現する「多段階プロンプト設計」

AI-OCRの「心臓部」であるGemini APIには、「Gemini 2.5 Pro」を採用しました。Gemini 2.5 Flashモデルよりも、長文で複雑な書類の理解に優れていたためです。
ただ、「Gemini 2.5 Pro」でも対処しきれなかった大きな課題がありました。それは、書類のフォーマットや項目名の「揺らぎ」が大きすぎることでした。

例えば、同じ項目でも「合計金額」と「Total」のように表記が異なったり、手書きや低画質スキャンで文字自体が判読しづらかったりするケースです。
単純な「この項目を読み取って」というプロンプトでは、精度がまったく安定しませんでした。

解決策：処理を2段階に分割する

そこで、AIへの指示を一度に行うのではなく、処理を「①分類 → ②読取・整形」の2段階に分割する「多段階プロンプト設計」を採用しました。

Step1 (分類)：まずAIに「これはA形式か？ B形式か？」を内部的に判断させます。
- 工夫した点：この分類結果はユーザーには見せないため、「出力禁止」ルールを明示し、処理専用の「判定フラグ」だけを出力させるようにしました。
Step2 (読取・整形)：Step1の分類結果をトリガーに、「もしStep1がAならこの指示、Bならこの指示」と、自然言語で処理を分岐させます。
- 工夫した点：これにより、AIは一度に考える範囲が狭まり、混乱がなくなりました。結果、A形式ならA形式の読取に、B形式ならB形式の読取に集中でき、精度が劇的に向上しました。

安定化のためのテクニック

さらに、出力の安定性を確保するために、以下のようなテクニックをプロンプトに盛り込みました。

セクション化：プロンプトを「#条件」「#出力例」「#共通ルール」のようにセクション分けし、AIの可読性を上げ、指示の意図を明確に伝えます。
明示的な出力形式の指定：「必ずJSON形式で出力すること」「説明文やコードブロックは絶対に含めないこと」など、曖昧さを排除するルールを細かく設定し、出力形式を固定化しました。

# 役割
あなたは **{専門分野または職務名}** の専門家です。  
与えられた入力データ（または添付ファイル）を基に、指示されたステップを正確に実行してください。

# ワークフロー定義
## Step1
### トリガー
{いつ・どんな条件でこのステップが発動するかを記述}

### 指示
{このステップで行う処理内容を具体的に記述}

### 条件
- {実行時に必ず守るルールや前提条件を箇条書き}
- {内部処理／ユーザへの出力の有無なども明示}

### 出力例
```
{出力フォーマットの例を記載}
```

## Step2
### トリガー
{前ステップの結果や条件を満たしたときに実行}

### 指示
{このステップの主な目的を説明（例：データ抽出・分析・変換など）}  
以下の条件を順守して結果を出力してください。

### データ（抽出または生成する要素）
- 

### 共通条件
- {出力ルール（形式、空欄処理、禁止事項など）}
- {データ補正・整形ルール}
- {表記統一・書式制限など}

### 形式別条件（またはケース別条件）
#### Aの場合
{処理内容}

#### Bの場合
{処理内容}

#### Cの場合
{処理内容}

### 出力例
```
{期待する最終出力例（例：CSV行、JSON、テキストなど）}
```

# 最終的な出力例
```
{最終的な出力フォーマット例（シンプルな完成形）}
```

ポイント②：GASの6分の壁を突破する「タスクキュー構成」

もう一つの大きな壁が、GASの「実行時間6分の壁」です。

当初の構成では、Googleフォーム送信をトリガーに、1つのGASが「スプレッドシート作成 → OCR処理 → 通知」のすべてを一気通貫で行っていました。
しかし、GeminiによるOCR処理は「添付ファイル数」と「1ファイルあたりのデータ量」に比例して時間がかかります。ファイルが数件あるだけで、簡単に6分の上限を超え、処理がタイムアウトしてしまう問題が発生しました。

解決策：「タスクキュー構成」で処理を分割

この問題を解決するために、処理を2段階に分割し、時間差で実行する「タスクキュー構成」を採用しました。
GASはシングルスレッドなので並行処理（マルチスレッド）ができません。そこで、「1回の実行で1件だけ処理し、残りは次のトリガーに回す」という仕組みを構築しました。

構成の詳細

Step1：初期セットアップGAS (フォーム送信トリガー)
- 役割：フォームが送信されたら「即時」に実行されます。
- 処理内容：フォルダ作成、スプレッドシート生成、そして「後でOCR処理するために必要なメタ情報（ファイルIDなど）」をキュー（処理待ちリスト）に保存します。
- ポイント：時間のかかるGeminiの処理はここでは一切実行しません。数秒で処理を完了させます。
Step2：OCR実行GAS (時間ベーストリガー)
- 役割： 1分ごとに自動実行されます。
- 処理内容： Step1で保存されたキュー（メタ情報）を参照し、「未処理のファイル」を1件だけ検索します。該当ファイルが見つかれば、その1件だけOCR処理（Gemini API呼び出し）を実行し、結果をスプレッドシートに追記します。
- ポイント：このGASは、1件処理したら終了します。そして1分後にまた起動（LockService で同時実行は防止済み）し、次の「未処理ファイル」を探します。1回の処理が6分以内に収まることは確認できているので、何十枚のファイルがあっても安定的に処理できるシステムが完成しました。

4. 導入効果：AI-OCRがもたらした業務スピード

このシステムを導入した結果、クライアントの業務が改善されました。

業務スピードの向上：これまで外注し、データが戻ってくるまで待っていた作業が、クライアント自身の手元で即時完結できるようになりました。
コスト削減とコントロール：外注コストが不要になっただけでなく、「自分たちで業務をコントロールできている」という安心感にもつながりました。

クライアントからは「作業完了までの時間が大幅に短縮され、本当に助かる」という、嬉しいフィードバックを直接いただくことができました。

5. まとめ：AI-OCR開発で得た学びと今後の展望

最後に、このプロジェクトを通して私が得た学びと、今後の展望について共有します。

AIコーディングは「分割」と「明示」が鍵

複雑な処理を一度にAIへ指示すると、意図しない動作や誤補完が発生しがちです。

「機能単位で処理を分割する」「入力の背景や期待する出力形式を明示する」ことで、AIの精度と再現性は格段に向上しました。
これは、AI開発特有のテクニックというよりは、通常の開発における「責務分離」や「明確な仕様定義」といった基本思考と全く同じだと再認識しました。

ツールの「制約」こそが最適な設計を生む

GASの「実行時間6分」「シングルスレッド」といった制約は、一見すると厄介な制約です。

しかし、この制約を前提として「どう回避するか」を真剣に考えたからこそ、今回の「タスクキュー構成」というアーキテクチャにたどり着けました。
制約を理解することこそが、最適な設計を生み出すためのヒントになると学びました。

開発者の役割は「プログラマー」から「設計対話者」へ

生成AIの進化は凄まじく、今やコーディング補助だけでなく、要件定義やテストも支援できるレベルにあります。
今後は、開発者の中心的な作業が「コードを書くこと」から、「AIといかにうまく対話し、最適な設計を引き出すか」という方向に向かっていくと強く感じました。

今後の展望

今回のAI-OCR開発で得たプロンプトエンジニアリングやアーキテクチャのノウハウは、他の多くの業務にも応用可能です。
この知見をもとに、クライアントの属人化しがちな業務や手作業の多いプロセスに対し、AIや自動化ツールを活用した、より高度な効率化の提案・実装に挑戦し続けたいと考えています。
この記事が、Gemini APIの活用や業務改善のヒントを探している方々の、一助となれば幸いです。

また、本プロジェクトは、開発自体もそうですが、何より入社して1年目でやり遂げた初めてのプロジェクトということもあり、たくさんの苦労がありました。
その苦労については、いつか note の方にも綴りたいと考えています！

最後までお読みいただき、ありがとうございました！

一緒に働く仲間を募集しています！

スタイル・エッジでは、一緒に働く仲間を募集しています！

もし少しでも「AIで業務を効率化してみたい！」と感じたなら、ぜひ私たちと一緒にチャレンジしてみませんか？弊社では、「Google Workspaceに興味がある人」「業務改善したい人」を大募集しています。

少しでも興味があれば、下記の採用サイトをご覧ください！💡

recruit.styleedge.co.jp

はじめに

① 事後学習：モデルは事前学習だけで完成しない

出てきやすい表現

落ち着いて読むための見方

② 有効コンテキスト：100万トークン入ることと、使えることは違う

出てきやすい表現

落ち着いて読むための見方

③ ベンチマーク飽和：高得点でも差が読みにくくなる理由

出てきやすい表現

落ち着いて読むための見方

おわりに

はじめに

2回目のAWS Jamを開催した背景

開催までの準備

メンバーの選定

一番苦労した「問題選定」

事前の周知

当日の様子

タイムスケジュール

開催者としての立ち回り

解説を自分で作ってみて

参加者からのリアクション

AWS Jamイベント全体の満足度を教えてください

内容の難易度はいかがでしたか？

AWSアーキテクチャ設計に対する理解度は深まりましたか？

今後もAWS Jamイベントがあれば参加したいですか？

次回に向けて

おわりに

一緒に働く仲間を募集しています！

はじめに

参加の目的

会場の様子・企業ブース

セッションレポート

生成AI時代にこそ求められるSRE

基本情報

概要

主なポイント

SREが提供すべき「コンテキスト」と「ガードレール」の分類

得られた学び

ゼロからはじめるSRE：一人運用から複数プロダクト・SREチーム立ち上げまでの軌跡

基本情報

概要

主なポイント

AWS移管後に行われた主な運用改善

得られた学び

Embedded SREの終わりを設計する 〜 「なんとなく」から計画的な自立支援へ 〜

基本情報

概要

主なポイント

得られた学び

全体の感想

おわりに

最後におまけ

はじめに

想定シナリオ

王道パターン：Webhook 利用

Webhook 以外の連携方式を色々考えてみた

プランA：割り切って、自動連携できる範囲のメリットは享受して、残りは手動で対応する

プランB：Pull方式（CRM から外部サービス側の API をコール）にしてタイミングを握る

プランC：Webhook + API のハイブリッド

プランD：ブラウザ拡張／ブックマークレットで「転記しやすい形」に整える（半自動化）

おわりに

はじめに

1. 課題：外注せざるを得なかった「手入力」の悩み

2. 解決策：Google Workspaceで作る「AI-OCR」の全体像

処理フロー

3. 実装ハイライト：立ちはだかった2つの技術課題

ポイント①：高精度を実現する「多段階プロンプト設計」

解決策：処理を2段階に分割する

安定化のためのテクニック

ポイント②：GASの6分の壁を突破する「タスクキュー構成」

解決策：「タスクキュー構成」で処理を分割

構成の詳細

4. 導入効果：AI-OCRがもたらした業務スピード

5. まとめ：AI-OCR開発で得た学びと今後の展望

AIコーディングは「分割」と「明示」が鍵

ツールの「制約」こそが最適な設計を生む

開発者の役割は「プログラマー」から「設計対話者」へ

今後の展望

一緒に働く仲間を募集しています！

Embedded SREの終わりを設計する〜「なんとなく」から計画的な自立支援へ〜