AI AgentのタイムアウトからGoのイテレータを俯瞰する こんにちは、岩﨑 ( @uho-wq ) です。 デリッシュキッチン開発部でプレミアム機能を開発しています。 先日、アプリ版デリッシュキッチンでGenerative UIを搭載したデリッシュAIをリリースしました。 この記事ではAI Agentが引き起こしたタイムアウトのバグから、Go 1.23で入ったイテレータについて俯瞰してみたいと思います。 デリッシュAI デリッシュキッチンでは、AIアシスタントと対話しながら作りたいレシピを探すことがで

こんにちは、QAコンサルタントのヤマダです。 ソフトウェア開発の現場では、日々、品質の確保、生産性の向上、そして技術の継承といった課題に直面します。経験豊富なエースエンジニアの活躍で一時的に問題が解決されても、そのノウハウがチームに共有されなければ、同じ問題が繰り返し発生してしまいます。 こうした「属人化」という名の落とし穴を避け、チームとして継続的に成長していくために不可欠なのが 「標準」 という考え方です。 「標準」と聞くと「形式的で堅苦しい」「創造性を縛るもの」といったネガティブなイメージを持つ方が

2026 年 9 月 25 日、 Amazon CloudWatch は CloudWatch Omni を発表しました。これは、アプリケーション中心で AI を活用し、オープンスタンダードに基づいて構築され、オフコンソールで提供される、アプリケーションと AI ワークロードの統合オブザーバビリティエクスペリエンスです。CloudWatch Omni は、AI エージェント向けに特化して構築されたオブザーバビリティ、評価、実験のためのソリューションです。評価主導のワークフロー、既存のツールのサポート、そし

財務アナリストが AI アシスタントに「私の担当する顧客請求書のうち、支払期日を過ぎているものはどれですか？」と尋ね、SAP から直接その答えが返ってくる、そんな場面を想像してみてください。企業はまさにこれを求めていますが、AI エージェントを記録システムに接続する際には難しい問いが生じます。エージェントが SAP にアクセスするとき、そのリクエストを行っているのは誰なのか、という問いです。初期の統合の多くは、すべてのリクエストを 1 つの共有 SAP サービスユーザー経由でルーティングします。これでは、

Webやアプリケーション開発において「アクセシビリティ」や「ユーザー補助」という言葉を聞くと、皆さんはどう感じるでしょうか。「重要だとはわかっているけれど、開発コストがかかる」「一部のユーザーのための特別な対応」といったイメージを持つ方も少なくないかもしれません。 しかし、技術的な観点からアクセシビリティの構造を紐解くと、そこにはエンジニアにとっても合理的で、美しいアーキテクチャが存在します。 結論から言うと、アクセシビリティ対応とは「ユーザーのための特別なUIをゼロから作る」ことではありません。 「ユー

本ブログは 株式会社クリエイティブ・ウェブ 様 と Amazon Web Services Japan 合同会社 が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの森です。 コンタクトセンターにおけるオペレーターの育成は、多くの企業が抱える共通の課題です。新人オペレーターが実際の顧客対応で必要なスキルを身につけるには、ベテランスタッフによるロールプレイ研修が欠かせません。しかし、研修のためにベテランを長時間拘束することは現場の運営負荷を増大させ、研修の頻度や品質にもばら

はじめに こんにちは、ZOZOTOWNのカート・決済・注文作成を担うバックエンドエンジニアの斉藤です。普段は開発に加えて、チームのマネジメントを担当しています。 影響調査そのものは、どのチームでも日常的に発生します。私たちの場合に問題だったのは、待たせる相手がいることでした。何か手を入れようとするたびに、影響範囲の洗い出し・実現可能性の判断・概算見積もりが必要です。これに毎回まとまった時間がかかります。その間、問い合わせ元である他部門は次に進めません。私たちの調査速度が、そのまま他部門の意思決定の速さを決

Amazon CloudWatch は、アプリケーションと AI エージェントを一緒に実行するための、AI を活用したオブザーバビリティエクスペリエンスである CloudWatch Omni を提供するようになりました。Omni には、組織専用の URL からアクセスし、すでに管理している ID でサインインします。そのため、Omni を使用するために AWS Management Console へのアクセス権は必要ありません。Omni は OpenTelemetry を基盤として構築されています。すで

はじめに dbt Labsが提供している「dbt Analytics Engineering Certification Exam」を受験し、無事合格することができました。 この記事では、これから受験する方の参考になればと思い、 試験の概要 実際に行った勉強方法 試験申し込み・受験環境の準備 試験当日に知っておくとよいこと について、私自身の受験経験をもとに紹介します。 本記事で扱う「dbt Analytics Engineering Certification Exam」の合格後に発行された認定証です。

サーバーワークスの村上です。 AWSがOSSで公開しているContext Ontology Accelerator（以下、COA）について検証した内容を紹介します。 一般的な理解・概念を知りたい方は以下のブログをご参照ください。 blog.serverworks.co.jp オントロジーを具体例で理解する 1つ目：業績テーブル 2つ目：会計期間マスターテーブル 生成されたオントロジー クラス（owl:Class）＝「概念」を宣言する Datatype Property（owl:DatatypeProper

本記事は 2年目ウィーク 5日目の記事です。 📈 4日目 ▶▶ 本記事 ▶▶ ✒️ 1. はじめに：ジュニアエンジニア不要論が語られる中で 2. SREの概要 2.1 SREとは？ 2.2 信頼性を制御するために 定量的な管理 オブザーバビリティ ポストモーテム トイルの削減 3. SREを勉強しようと思ったら 4. 最後に こんにちは！柴原です。 最近は健康意識の高いプロジェクトメンバーに触発されて週4くらいでジムに行っています。通い始めて3ヶ月経ちますが、いつまで続くかは不明です。 さて、私事ではあり

はじめに # GFXBenchというGPUベンチマークソフトを取り上げたシリーズの3回目です。 前回までで新しいAndroidバージョンで実行が行えました。 今回からは古いAndroidバージョンでの実行を試みてみます。 ソースコード準備 # 前回までのAPKファイルを古いAndroidバージョンで実行するとエラーが発生し（詳細は後述）ベンチマーク実行不可でした。 エラー原因からソースコードを修正して回避出来ないか検討してみます。 修正方針 # 修正方針も色々あるかと思いますが、今回の前提としてAndro

 この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。  判断の積み重ねは、いつしか慣習になります。そして一度慣習になると、誰も疑問を持たなくなります。前例踏襲という「思考停止」の完成です。今回からの3回は、そのひとつ、更改案件の「現行機能保証」を扱います。対処するには3つの視点が必要で、それぞれをサブテーマとして、3回に分けて扱います。 第3回（本稿）: 「現行」の実体を見る 第4回: 合意できる「全体像」を作る 第5回: 検証し、予算を組み、配分する  この3本の

 この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。  更改案件の「現行機能保証」を3つのサブテーマに分けて扱う、その2回目です。前回（第3回）は、「現行」と呼ばれるものの実体が3つあることを見て、最後に「確定」という前提を疑いました。本稿では、発注側と合意できる「全体像」の作り方を考えます。 質問 #  既存システムの更改案件で、アジャイルで進める提案をしたところ、発注側から「見積の根拠として機能一覧を出してほしい」と言われました。「アジャイルは最初に全件を確定し

こんにちは。インフラグループ Kubernetesチームのmendです！ 私たちのチームでは、マイクロサービスの実行環境として、AWS上のKubernetes（EKS）を活用しています。 現在、長年クラスタの入口として活躍してくれた「Ingress-NGINX」がEOLとなりましたので、次世代規格であるGateway APIに準拠した 「NGINX Gateway Fabric」 への移行を行いました。 今回は、移行を決めた背景から、 AWS Load Balancer Controller ＋ exte