エンジニアのAI活用事例

全米の市議会や都市計画委員会の会議は録画されても中身が追えず、誰がどの立場を取ったかが分からなかった。

音質も自治体ごとにばらばらで、会議が5時間を超えることもあった。

1. 会議の録画を音声認識APIに渡す
2. 話者分離で文字起こしする
3. Speaker Identificationで実名を結び付ける
4. 自前の処理で発言者を二重三重に確かめる
5. 時刻付きで検索できる記録として公開した

住民や記者が自分の市議会議員の発言履歴を調べられる無料のツールを公開した。

対象は数千の市にまたがる1万人以上の議員で、話者の識別では基盤モデル単体の3倍の価値を上乗せできたとしている。

ノードごとに最大の電力を押さえて確保していたため、実際には使われない電力が各ノードに閉じ込められていた。

施設全体では上限に届かないのに、GPUを増やせない状態が続いた。

1. GB300 NVL72のラックでKimi K2.5をFP4で動かした
2. 処理量を重視した推論と低遅延の推論を混ぜた
3. DSX MaxLPSでノード間に余った電力を回した
4. 電力会社の合図をDSX Flexで受けGPUの上限を自動で下げた
5. 140基の構成で基準を測り192基の構成と比べた

全体の推論の処理量が49.2%増え、確保した1ワットあたりの処理量も同じだけ上がった。

先に動いていた枠の性能は落ちず、需要の合図への対応ではGPUの電力を25%下げた状態を30分保てた。

冷却と電力と工程の解析が別々の道具に分かれていて受け渡しに手間がかかっていた。

新しい市場に向けた仕組みを短い期間で形にする必要もあった。

1. OpenUSDで部品ごとに分けた作りにした
2. Omniverseとつなぐ部分の骨組みと最初のテスト用例をAIに作らせた
3. 描画で重い計算をしている箇所を洗い出しGPU側へ移した
4. 顧客の声をすぐ試作に起こして短い周期で確かめた
5. 人がコードの確認と自動テストで品質を保った

最初の打ち合わせから4週間で動く試作ができ6か月で端から端まで通したMVPを出した。

検証済みの部品データから画面を自動で組み立てるので準備は数日から数時間に縮んだ。

AIが書くコードが増えてレビューの量に追いつかなくなった。

レビューが遅いと開発そのものを止めてしまう。

1. プルリクエストが上がるたび自動でレビューを始める
2. 差分だけでなくリポジトリ全体を読んで指摘する
3. 下位のエージェントを立ち上げ複数のモデルで分担する
4. オープンモデルの推論をTogether AIの基盤で動かす
5. コードを書いたモデルとは別のモデルが見る形にした

レビューの質を落とさず所要時間が半分になった。

最初の試用の段階で求めていた応答の速さを満たしたのでそのまま採用を決めた。

少人数のチームで規模の大きい開発を進める必要があった。

製品が変わるたびに社内の説明資料が古くなりPMがコードの変更を毎回文章に直していた。

1. チケットごとに目的と受け入れ条件をつなげた
2. 同じ材料をCursorのエージェントに渡して開発させた
3. コードのどこを読むか案内する地図を用意した
4. 3つのツールで説明を書き2人が確かめて正式版にした
5. 取り込みのたび影響するページの修正案を出させる

ユーザーストーリー1本の提供が約10日短くなり開発の効率は41%上がった。

ドキュメントの確認は週約10時間から約90分になり1人あたりの提供価値は73%増えた。

9社の航空券の仕入れ先ごとに仕様がばらばらで、運賃が出ない・座席が選べないといった穴が利用者に見えていた。

資料の無い仕入れ先もあり、原因調べに何日もかかっていた。

1. 予約の機能を検索や発券などに切り分けた
2. 仕入れ先ごとに設計の仕様書を書いてから実装した
3. 10万行超のAPI仕様をCursorに読ませ必要な所を探した
4. Pythonの中継プログラムを作り手元から試せるようにした
5. 実行環境をJava 8からJava 21へ移した

2〜3日かかっていた原因調べが約半日で終わるようになった。

往復検索の応答はp95で10秒から8秒になり、運賃ルールの網羅率は80%から90%へ上がった。

AI向けの複雑なチップが増え、設計と製造のシミュレーションに膨大なCPUの計算時間がかかっていた。

マスク1組で3,000万時間以上のCPU計算が必要になることもあり、技術者は結果を待たされていた。

1. マスク合成ソフトのProteusをcuLithoと組み合わせる
2. 並列性の高い計算をCPUからGPUへ移す
3. 計算をNVIDIA B200 GPUの上で動かす
4. CUDA-Xのライブラリで既存のソルバーも速くする
5. 材料探索ではQuantumATKをcuESTで最適化する

露光計算のシミュレーションはCPUのモデルに比べて最大20倍速くなる見込みになった。

Applied Materialsの初期の結果では量子化学の計算が30倍速くなる可能性が出て、Northrop Grumman Microelectronics Centerでは開発が数週間から数時間に縮んだ。

30年以上動かしてきたIBM i上のRPGアプリが600万行を超え、積み上がった古い作りと埋め込まれた業務ルールで手が付けられない状態だった。

1日に何百万件ものAPIの呼び出しをさばく必要もあり、作り替えの道筋が見えなかった。

1. Ensonoと組んで今の仕組みを調べることから始める
2. IBM Bobに600万行のRPGコードを読ませた
3. 設計は上からコードは下から両方向でたどる
4. Bobが最新の仕様の文書を自動で作った
5. 残すところと部品に分けるところを決めて計画に落とす

ふつうなら数か月かかる評価を6週間で終えた。

Bobは他のツールより最大4倍速く結果を出し、それまで見えていなかった要点も掘り出した。

ログと指標と通知が4つの別々の仕組みに散らばり、障害のたびに画面を行き来して原因をたどる必要があった。

監視の仕組み自体が監視対象と同じ基盤の上で動いていたため、障害が起きると状況が見えなくなる弱点もあった。

1. 4つに分かれていた監視をObserve by Snowflakeへ寄せた。
2. Kubernetesの各クラスタにエージェントを入れた。
3. 米国とEUで別テナントを用意し設定はTerraformで管理する。
4. 集めたテレメトリーを社内のAIエージェントにつないだ。
5. エンジニアはSlackで疑問を投げて答えを受け取る。

障害対応にかかる時間の中央値が約80%短くなった。

年10万ドル超のAWSの費用も要らなくなり、障害時に状況が見えなくなる弱点も消えた。

顧客から修正の依頼が来るとLinearのチケットとSlackのやり取りに情報が散らばった。

全体像をつかむまでに時間がかかりコードを書く所だけが速い状態だった。

1. eveという枠組みでエージェントを作りVercel上で動かした。
2. 指示書とツールと手順を1つのフォルダにまとめた。
3. 担当者はChrome拡張で直したい内容を書いて渡す。
4. コーディング担当のエージェントが仕様とプルリクエストを作る。
5. 責任者が内容を見てから取り込む。

直近3か月で出荷の速さが3倍になった。

2人のチームは最初の4か月でLinearのチケットを800件以上終わらせ顧客の依頼は早いものだと2時間で本番へ入るようになった。

顧客が求めるレポートが細かくなるほど、ダッシュボードの設定と検証に何時間もかかっていた。

数千万行の取引データを数百の列で扱うため、手作業の組み立てと確認が重かった。

1. Workbooks as Codeでワークブックをコードとして読み書きする
2. 画面で一つずつ設定する作り方をやめた
3. レポートの構想やモックをAIに渡し下書きを作らせる
4. できた下書きを見ながら手を入れて仕上げる
5. 空いた時間は要件の詰めと使いやすさの確認に回した

最初の下書きが約4時間から10〜15分でできるようになり、約94%の短縮になった。

その後の作り直しも速くなった。

AIを使った開発を試しから本番の案件まで広げる段階で社員のスキルが追いつかなかった。

社内の研修や外部の教材はあったが、役割ごとに段階を踏む道筋がなかった。

1. ソフトウェアエンジニアを対象にUdemy Businessで研修を始めた。
2. UdemyのSkills Mappingで役割別の学習コースを組んだ。
3. 入り口のLevel0をAIの基礎として1,235人に必須にした。
4. Level1から3は役割ごとに学ぶ深さを上げた。
5. 進み具合は管理者別のダッシュボードに自動で出した。

Level0は88%が修了し、社員の62%が毎日の仕事でAIを使うようになった。

新規の開発案件では45〜55%の効率改善が出た。

大事な合図がメールのやりとりやセンサーの通知に埋もれて、判断が遅れていた。

管理の担当者は手作業でメールを振り分け、記憶を頼りに追いかけるしかなかった。

1. 自社のエージェント基盤にIBM Bobの空間の理解を組み込んだ
2. カメラやセンサーの情報を人と場所と設備と出来事のつながりに整理させる
3. 複数の形式を合わせて考える部分はIBM watsonx.aiに任せた
4. メールと予定表と商談の情報をつないで急ぎ具合で並べ替える
5. 提案は下書きで出して人が承認する形にした

管理職はメールの振り分けと打ち合わせ前の下準備や予定の調整で週8〜12時間を浮かせた。

必要な情報にすぐ届くようにもなった。

Vodafone Ideaは150を超えるアプリを止めずに更新していて、開発の進め方がチームごとにばらばらだった。

同じ作業を別々のチームが繰り返し、分かったことも共有されないまま開発が遅れていた。

1. IBM Consulting Advantageを開発の流れ全体に入れた
2. 業務分析から障害調査まで120超のAIアシスタントを用意した
3. 機密の文書を扱う場面はインド国内のLLMサービスへ回す
4. 検証を通ったアシスタントだけをチーム全体へ広げる
5. 社内のハッカソンで138のユースケースを集めた

生産性は25〜30%上がり、市場に出すまでの時間も25〜30%短くなった。

IT業務の工程のうち約55%に生成AIが入り、80%超を目指す計画になっている。

ScribdとSlideshareに利用者が上げた文書は4億件を超え、規約に反する中身がないか見きれなくなっていた。

中身の種類ごとに専用の判定モデルが必要で、自前で作れば何年もかかり外部の製品では費用が見合わなかった。

1. 判定する文書をCloud Storageにまとめて置く。
2. Gemini Enterpriseのバッチ予測へまとめて投げた。
3. 判定役はGemini 2.5 Flash Liteにする。
4. PDFを変換せずそのまま渡して文字と画像を読ませる。
5. 出力はGemini 2.5 Proで全件もう一度見直させた。

ScribdとSlideshareにある4億件を超える文書（120億ページ超）を数か月で判定し終えた。

全体の99%以上は前処理なしでそのまま読ませられ、バッチ予測は対話で使うより50%安い料金で回せた。

1年前まで仕事は受信箱とチャットと表計算に散らばっていた。

技術者は最初のコードを書く前に自分で朝会の報告を書き、問い合わせは1つの窓口に積み上がって手で振り分けていた。

1. 仕事の置き場をClickUpの1つの作業場にまとめた
2. Echoが作業の記録を読み朝会の原稿を先に書いた
3. Delegatorが届いた依頼を担当チームへ振り分けた
4. Notetakerが通話を担当者と期限の付いたタスクに変えた
5. ClickUp Brainが期限を過ぎそうな作業を知らせた

製品を出す直前にBrainが見落としの5件を見つけ、3日の遅れを避けて予定どおり公開できた。

4つのチームが1つの作業場で動くようになった。

社内向けの埋め込みサービスはOpenSearchで動いていたが、使うチームが増えて扱う埋め込みは数億件になった。

速度を保つには調整を続けるしかなく、クラスタが大きくなるほど費用も膨らんだ。

1. 本番の使われ方に近いベンチマークを自分たちで組んだ
2. 1億件の埋め込みを載せ同時に走らせる数を増やした
3. 近傍検索と絞り込み付き検索と読み書き混在の問い合わせを流した
4. 同じ条件で比べぶれが最も小さいWeaviateを選んだ
5. 出入り口を社内サービスで隠していたので設定の書き換えだけで移った

ベンチマークではWeaviateがOpenSearchより20倍速く、運用の費用は40%下がった。

社内の色々なAIの仕組みが同じ基盤に乗るようになった。

製品ごとの炭素排出量を出すには、何万行もの部品表を人が1件ずつ調べる必要があった。

仕入れ先の資料は形式がばらばらで抜けも多く、評価が終わる頃には製品が発売済みということも起きていた。

1. 部品表やPDF・CAD図面・仕入れ先のメールを取り込んだ
2. 製品と供給網をつないだ炭素のグラフに作り直す
3. 部品表の各行を約100種類の分類へ振り分けた
4. 1万件を超える排出係数から近いものを選ぶ
5. 3つの処理をNVIDIA Nemotron 3 Ultraへ載せ替えた

仕入れ先データの読み取りは84.0%から87.7%へ、部品の分類は80.0%から83.5%へ上がった。

コストは0.20倍と0.49倍になり応答の速さも前のモデルと同じか速くなった。

AIアシスタントの利用が広がり、預かる会議の記録や個人のメモなどの機密性が高まっていた。

鍵や秘密情報の管理は手作業で散らばり、どう守られているかが見えにくかった。

1. IBM Vaultを入れて機密データと秘密情報の管理をまとめた。
2. 組織と利用者とセッションごとに区切りを作りデータを分けた。
3. 鍵の入れ替えと監査の記録とルールの適用を自動で回す。
4. 人が手で持っていた鍵は中央でまとめて管理する形にした。

暗号処理の監査は100%カバーになり、全てのテナントで止めずに鍵を入れ替えられるようになった。

本番環境から平文の機密データが消えてVaultのAPI呼び出しも96%減った。

英国から米国へ広げたあと欧州へ出るにあたり、複数の言語に対応する必要が出た。

地域ごとの用語が揃わず自社らしい言い回しが訳で消える心配もあった。

1. コネクタを2つつなぎ作業の流れの中から翻訳を出す
2. 主要な3言語を自社向けに調整したAIモデルで訳す
3. 出てきた訳は専門の翻訳者が確認して直した
4. その直しを次の訳に反映させる
5. 用語や言い回しの決まりはモデル側に持たせる

新しい製品を出すときの翻訳が速くなり品質も保てるようになった。

金融の規制に合う安全面の審査も通り、欧州へ広げ続けられる形になった。

各チームが思い思いにベクトルデータベースを入れ始め、1か月で4〜5種類が社内に並んだ。

支える仕組みが膨らむ前に1つに決める必要があった。

1. リードのエンジニアが各チームに必要な条件を聞き取った
2. 毎秒のクエリ数や導入の速さや高可用性で候補を比べた
3. AWS EKS上に検査済みの雛形でWeaviateを載せた
4. ハイブリッド検索や再ランクを自作せずアプリ作りに集中した
5. 社員は社内チャットにファイルを上げて中身を質問する

1年かからずにAIを使った商品を世に出せた。

コードが書けない社員でも、自分のファイルを上げて質問できるようになった。

バグ票のやり取りが長く状況をつかむだけで20分以上かかっていた。

QAと開発が同じスレッドを別々に読み直すため手間が二重になっていた。

1. QAがバグのタスクを開いてClickUp Brainに要約させる
2. 検証済みの内容と残りと本当の原因を数秒で受け取る
3. その要約をもとに人が返信してチケットを次へ進める
4. バグ要約と状況把握と振り分けの3つのエージェントを組んだ
5. 設定は初日に済み調整の前から使える要約が出た

スレッド全体を読む20分以上の作業が数秒の要約に置き換わった。

ログが散らばって更新が食い違う難しいバグでも要点を外さなくなった。

翻訳を1社の会社に任せきりで手作業と調整が多かった。

社内のシステムともつながっておらず製品を各国へ出す速さに追いつけなかった。

1. 自社向けに学習させた翻訳モデルを使う
2. GitHubやDrupalとつなぎ書いた場所で訳す
3. 担当者が自分で依頼を出し流れを設定する
4. モデルが実際の直しから言い回しを学ぶ
5. 管理者も自分で案件を動かせるようにした

翻訳にかかる費用が下がり納品までの時間も短くなった。

開発者は翻訳の作業から離れてコードを書くことに集中できるようになった。

テストの担当者が長い要件定義や機能仕様、あちこちに散ったコメントを毎回1行ずつ読んでいた。

テストを始める前の下調べだけで週に3〜4時間が消えていた。

1. 品質チェックの作業をClickUpへ寄せ仕様書とタスクを同じ場所に置く。
2. 自分たちで組んだSuper Agentに仕様書を指し示して渡す。
3. ClickUp Brainがテストの筋書きと確認手順を組み立てて返す。
4. 出てきた結果を見て担当者が足りない観点を補った。

仕様書からテストケース一式を作る時間が1分未満になり、週3〜4時間かけていた下準備が消えた。

ログイン機能の改修では期限切れトークンや転送先の抜けといった条件を機械側が指摘し、本番に出る前に見つけられた。

食事・運動・睡眠・活動量のデータが別々の仕組みに散らばっていた。

利用者はフィルターや一覧画面から自分で探すしかなく、トレーナーも手作業の分析に時間を取られていた。

1. 整理した健康データをベクトルデータベースへ入れる
2. 意味の近さでデータを探せる状態にする
3. 利用者が普通の言葉で聞いた内容をQuery Agentが受け取る
4. 必要なデータを選んで取り出し読みやすい返事にまとめる
5. 決めた基準を超えたときに助言が自動で出るようにした

利用者は従来の画面よりも会話で3倍多くやり取りするようになった。

トレーナーの分析時間は60%減り、指導そのものに時間を回せるようになった。

APIを作った後のテストや文書や仕様の更新がばらばらの手作業で残り、変更のたびに中身がずれていた。

自社の調べでは開発者の69%がAPI関連の作業に週10時間を超えて使っていた。

1. 開発とコーディングの課題で複数のモデルを比べた
2. Agent Modeの既定にClaude Opus 4.6を選ぶ
3. Amazon Bedrock経由で数時間でつないだ
4. コレクションやテストやGit履歴を読ませる
5. エンドポイント指定でテスト作成と仕様更新まで任せる

自社の見積もりでは開発者1人あたり年間で最大1,150時間を削れる。

10人のチームなら年間で100万ドル近い費用の削減にあたる。

技術者ごとに好みの開発環境が違うため6種類のコーディング支援を用意したが、社外のパッケージを各自で入れる形は供給網を狙った攻撃の危険があり配布に踏み切れなかった。

1. Anthropicと組み署名済みの法人向けバイナリを作る。
2. 2〜3か月かけて検証と手直しを重ねた。
3. 全員のノートPCと開発機にあらかじめ入れておく。
4. ルールとトークンと認証まで設定済みにした。
5. AIを社内を知らない優秀な新人として扱うよう伝える。

あるチームが10,000行のScalaコードを4日でJavaへ書き換えた。

手作業なら10人週かかると見ていた仕事で、新しいJDKへ移れて性能の改善も進んだ。

PayPalのAPIは組み合わせが膨大で、加盟店が使い始めるまでに時間がかかっていた。

資料はJSONばかりで読み解きづらく更新にも追いつかなかった。

1. 公開APIの資料をPostmanの共有スペースにまとめた
2. そのまま複製して使えるコレクションとして配った
3. 複雑な決済の流れをPostman Flowsで図にした
4. Agent Modeで普段の言葉から手順を組み立てさせた
5. MCPサーバーを用意しClaudeやCursorから試せるようにした

最初のAPI呼び出しまでが1分になり、3年で10万件を超えるコレクションのフォークが生まれた。

加盟店が売上を立てるまでの時間も短くなった。

一人ずつにAIが付いても、確認のやり取りや日程合わせで仕事が止まる場面は減らなかった。

部署ごとにボットが散らばって何をしているか見えない状態も起きていた。

1. AI Teammatesの頭脳にClaudeを選んだ
2. 全体をまとめる上位のエージェントにClaudeを置いた
3. 下のエージェントは速さと考える力で使い分けた
4. Agent Skillsで文書編集機能の開発期間を縮めた
5. AIにアカウントを持たせコメントで呼び出した

キャンペーンの企画書は何日もやり取りしていたものが15分で確認できる下書きに変わった。

動いた内容はすべてタスクの履歴に残る。

週の進み具合をスプリント管理と会議メモとチャットに分けて追いかけており、まとめを夜遅くに手で書いていた。

問い合わせも1件ずつ人が読んで振り分けていて、忙しい時期は列が追いつかなかった。

1. ClickUpに開発と問い合わせと運用と宣伝を集める
2. ClickUp Brainがタスクや会議メモをつなぎ文脈を持たせる
3. 専用エージェントが問い合わせを仕分けし返信の下書きを作る
4. 会話をスプリントのまとめや積み残しの更新に変える
5. 手順書や新人向けの案内をAIが下書きし人が直す

小売向けERPの導入では人が気づく前にエージェントが請求と在庫をつなぐAPIの抜けを見つけ、予定どおりの公開を守れた。

新しく入った人も先輩に聞かずに自分で答えを探せるようになった。

1日50万件を超える形の違う書類を扱うのに、正確さと速さを同時に満たす基盤が無かった。

欧州や金融の顧客はデータを国外やクラウドへ出せず、置き場所も選べる必要があった。

1. 自社の使い方に合わせたベンチマークを先に作る
2. 取り出しの正確さと応答の速さで複数のDBを比べる
3. 選んだWeaviateへ書類から取り出したデータを入れる
4. 密ベクトルと疎検索を組み合わせたハイブリッド検索で引く
5. テナント単位で分けて保存し該当分だけを照会する

5万を超えるテナントを1つのクラスタに収め、特定のテナントのデータをミリ秒で引けるようになった。

1顧客向けに450種類以上のデータ型を取り込めた。

新しいモデルや連携をすぐ足さないと競合に先を越される状況だった。

ベクトル検索を後付けしたデータベースでは性能とコストの両立が難しかった。

1. Pinecone・ChromaDB・Qdrantと比べてWeaviateを選ぶ
2. 顧客ごとのデータをマルチテナントの仕組みで分ける
3. ハイブリッド検索とメタデータの絞り込みを合わせる
4. 規制の厳しい顧客はEnterprise Cloudで置き場所を分ける
5. 新しい機能は技術チームと詰めて実装を早める

Pineconeを使う場合と比べて数万ドル規模のコストを抑えられた。

規制の厳しい業界の企業にも環境を分けて提供できるようになった。

公開直後に利用が一気に増え数万の顧客それぞれに分けた検索用の索引を1人で支えきれなくなった。

最初の作りでは規模に耐えられず顧客同士のデータが混ざる不安もあった。

1. 文書の取り込みと分割と埋め込みの生成を自前で行った
2. ベクトルとメタデータをWeaviate Cloudへ保存する
3. セマンティック検索とハイブリッド検索で関係部分を取り出した
4. 取り出した文脈をLLMへ渡して根拠のある回答を作る
5. 顧客ごとにテナントを分けてデータが混ざらないようにした

5万を超えるテナントまで広がり1年で610万件超の質問に答えられるようになった。

データベースの面倒をWeaviateに任せ創業者は製品づくりに時間を回せるようになった。

タスクや文書やSlackのやり取りに情報が散らばり状況を追うだけで手間がかかっていた。

会議の話を報告の形に整えるのにPMやデザイナーが30〜60分使っていた。

1. ClickUp Brainで役割ごとのエージェントを用意した
2. Echoがタスクと文書から日々の要約と進捗を作る
3. Sprint Assistantが目標を作業に分け滞りを知らせる
4. Design Flow AgentがUX調査のメモを説明書へ整える
5. Triage Agentが届いた依頼を担当チームへ振り分ける

手作業でプロジェクトの要約を作る時間が減った。

ある案件ではPM Update Agentがタスクの流れに埋もれていた開発とデザインの依存関係を見つけ同じ日に日程を直せた。

四半期ごとのまとめ処理に頼っていたため報告が遅れ、顧客がすぐに判断できなかった。

自前で動かすKafkaの手入れにも人手を取られていた。

1. Kafkaの自前運用をやめてConfluentの基盤へ移した
2. 用意された接続部品でSQLやMongoDBのデータをつないだ
3. 流れてくるデータをAzure OpenAIのモデルへ渡した
4. チャットボットが資料の要約と供給網のリスクを返す

1つのクラスタだった処理は複数のクラスタへ広がり、データの欠落は起きなかった。

障害の予測は以前の2分前から30分前になり、前より1,400%早くなった。

特許検索の意味検索を、ベクトル検索向けに作られていないLucene系のAWSサービスで動かしていた。

データを全部メモリに載せてハードを多めに用意する必要があり費用がふくらんでいた。

1. 自前で動かすFaissやMilvus・Pineconeと比べた
2. マネージド型のWeaviate Cloudを選んだ
3. 接続をWeaviateのPythonクライアントへ差し替えた
4. ハードの面倒はWeaviate側に任せた
5. 開発の担当を製品の機能づくりへ戻した

運用コストが80%以上減った。

インフラに手を取られなくなり、RAG分野の新しい機能づくりへ人を回せるようになった。

NAMIのサイトを多言語にするため表計算ソフトへ書き出し訳文を手でシステムへ戻していた。

工程が分かれていて時間がかかっていた。

1. 翻訳の速さと費用を基準にLILTを選ぶ
2. LILTをWordPressとつなぐ
3. コンテンツ集から数千件をまとめて取り込む
4. 訳した内容を開発で使える形式で書き出す
5. 表計算への書き出しと貼り戻しを無くす

訳したページを以前より早く公開できるようになった。

資料ページで扱う言語の数も増やしている。

開発ツールにAIを組み込みたかったが、どのモデルがコードの作業に向くか分からなかった。

1. 複数のモデルを比べAmazon Bedrock経由のClaudeを選んだ
2. エディタ内のコード生成と文書生成に組み込んだ
3. 社内の基準で品質を測った
4. コーディングエージェントのJunieで難しい作業をClaudeに任せた
5. 計画を開発者が承認したあとコードを書きテストまで走らせた

社内のベンチマークでドキュメント生成が19%良くなり、利用者が指示するリファクタリングの成功率は59%上がった。

タスクの完了成功率は53%以上になった。

急な成長で仕事がメールやJira・Teams・Outlookに散らばっていた。

案件の進み具合を知るには忙しい同僚に聞いて返事を待つしかなかった。

1. 全チームと案件と期限を1つのClickUpへ移した
2. 19のスペースに分け進捗の質問はClickUp Brainに答えさせた
3. 経営陣は動いているダッシュボードを見る形にした
4. SentryをClickUpにつなぎエラーで自動でタスクが立つようにした
5. 最初の仕様書はLLMが下書きし人が中身を見て手を入れた

12か月未満で6,000件を超えるタスクが1か所に集まり、Jira・Teams・Outlookは使わなくなった。

300人を超える会社が同じ情報を見て動くようになった。

チームも道具もばらばらで誰が何をいつまでにやるのかが分かりにくくなっていた。

生成AIで仕事の進め方を変えたかったが倫理や透明性の考え方が合う提供元を選ぶ必要があった。

1. 自社のWork GraphにClaudeをつないだ
2. 提供元の先行利用枠で一緒に検証しながら組み込んだ
3. 自動処理と4つのSmart機能を画面の中に置いた
4. 進捗報告の下書きや要約を出し最後は人が直す形にした
5. ベータ版の枠で独自の流れや先回りの通知も試している

数年かかると見ていた機能を少人数のチームが数週間で出せるようになった。

15万社を超える利用者側でも目標がはっきりし経営層の判断にかかる時間が減った。