はじめに こんにちは。スピーダ事業Product Teamの中嶋です。 今年のはじめから先月まで、大阪拠点の開発チームでお仕事をしていました。約半年ぶりに東京拠点での開発に戻り、どんなことがやれるのか少し楽しみにしている自分がいます。 さて、私たちProduct Teamでは、どこのチームでも1週間に1回ふりかえりを行っています。基本的には1週間というタイムボックスをふりかえり、その中で見つけた課題について深掘りし、アクションを立てて終わります*1。 ふりかえりのテーマはその都度その場で見つけて深掘りして

はじめに こんにちは、クラウドエースの梶尾です。 Google Cloud の運用保守を進める中で、「社内ネットワーク以外のIPアドレスからのアクセスを防ぎたい」という課題は避けて通れません。 正直なところ、Google Workspace の有料ライセンス（Context-Aware Access）を契約して入り口でシャットアウトするのが一番手軽かつ確実な方法です。 ただ、予算の都合で「ライセンス費用は出せないけれど、許可してないIPアドレスからのアクセスには即座に気づけるようにしたい」というケースは少

本記事は 2026 年 7 月 2 日に公開された Ranjith Ramakrishnan による “ Set a cap on overage spend, or pre-pay for it ” を翻訳したものです。 現在 Kiro で超過利用 (overage) をしている場合、いくら使ったかがわかるのは、すでに使い切ってしまった後です。ヘビーな利用の結果は翌月の請求書に金額として現れ、その時点ではもう支払うしかありません。チームで Kiro をご利用のお客様からは、自分たちでコントロールできる上

はじめまして、2026年5月からUzabaseで働いております。清水と申します。 自分のジョインしたチームでは、関数型言語であるClojureを使って開発しています。関数型言語での開発をきっかけに、関数型プログラミングの良さについて興味を持ったので、今回社内発表をしました。 関数型デザイン【委託】 - 達人出版会 なっとく！関数型プログラミング【PDF版】 ｜ SEshop｜ 翔泳社の本・電子書籍通販サイト https://www.goodreads.com/book/show/39996759-a-ph

はじめに こんにちは！同志社大学大学院 修士 1年の近藤 大輔です。 2026年6月3日 〜 6月3 ...

はじめに 2026年6月に約3週間、CA Tech Jobに参加しました、早稲田大学基幹理工学部情報 ...

社内のちょっとした業務効率化ツールを作りたいけれど、専用の開発ツールは操作を覚えるのが大変で腰が重い――そんな方に向けて、普段使っているAIチャット画面との対話を重ねつつ、実装までを進めたやってみた記録を紹介する記事です。実際に試して効果を感じたポイントをまとめてみました。

IoTの活用が広がる中で、本格的にビジネス活用に取り組む企業が増えています。 しかし、いざ構築・運用を始めると、遠隔デバイスの管理やセキュリティ確保に課題を感じるケースも多いのではないでしょうか。本記事では、NTTドコモビジネスが提供するIoT向けネットワークプラットフォーム「docomo business SIGN™」の機能の中から、運用に役立つ「デバイスアクセス」と「フローコレクター」を実際に試した様子をご紹介します。 はじめに docomo business SIGN™とは docomo busin

G-gen の杉村です。当記事では、Google Cloud の AI エージェント向けネットワークセキュリティ機能である Agent Gateway について解説し、仕様の把握や設計時の考慮事項の検討に役立つ情報を提供します。 概要 Agent Gateway とは アーキテクチャ メリット 通信制御 概要 通信制御の対象 Identity-Aware Proxy（IAP） Model Armor セマンティックガバナンスポリシー Service Extensions デプロイと運用 エージェントへのル

はじめに # Model Context Protocol (MCP) は、2024年11月の初版リリース以来、AIモデルと外部データ・機能を接続する標準プロトコルとして急速に進化してきました。 今回の2026-07-28 Release Candidate（以下、RC）は、単なる機能追加ではなく、プロトコルの実運用前提を大きく変える改訂です。 とくに注目すべきは、プロトコル層のステートレス化です。 セッション管理を外し、ロードバランシング・再試行・観測性・キャッシュ運用をHTTP標準に近い形へ寄せること

1. はじめに Claude Codeをはじめとするコーディングエージェントは、今や多くの開発者が日常的に使う道具になりました。私自身も毎日のように使っていますが、最近は使い方が少しずつ変わってきました。 コードを書かせる道具としてではなく、設計を詰めるための相手として使う 比重が、明らかに増えてきたと感じています。

金融IT本部の河岸です。 先日、クロスイノベーション本部の大岡叡さんが主催する「25卒合同AWS勉強会 #3」に参加してきました。本ブログでは、その様子をお届けします。 去年12月にスタートしたAWS勉強会も今回で3回目。今回は参加企業が7社、参加者は34名となり、コミュニティは回を重ねるごとに拡大しています。AWSを学ぶ同期たちが会社の垣根を越えて集まり、最新技術や実案件の知見を共有する場へと成長してきました。 (ぜひ 第1回 と 第2回 の記事もあわせてご覧ください！) 開催背景 イベント概要 イベン

AIエージェント開発でLLM as a Judgeを機能させるには、評価AIを用意するだけでは不十分です。人間の暗黙知を評価基準へ落とし込み、実行ログをテストケースとして蓄積し、評価器であるLLM自体のズレも継続的に点検する運用設計が必要です。 こちらの記事 では、AIがAIを評価する仕組みである「LLM as a Judge」の基本的な考え方を紹介しました。しかし、実際にLLM as a Judgeを導入するのはそう簡単ではありません。 本記事では、dotDataで開発した「UseCase Adviso

テスト観点が書けない・・・・、その壁、壊せます。 前回の記事で「テスト観点で語れ」「足りない観点を指摘しなさい」と書きました。でも、こう思った人もいるんじゃないでしょうか。 「で、テスト観点ってどうやって書くの？」 テスト観点という言葉は知っている。大事なのもわかる。でも、いざ書こうとすると手が止まる。何を書けばいいのか、どこまで書けばいいのか、これで合ってるのか。その不安が、最初の一歩を阻んでいます。 この記事では、テスト観点が書けない原因を3つの壁に分解して、それぞれの乗り越え方からチームでの運用方法

オフショア開発で品質を担保するために実践している3つのこと こんにちは。自社運営webサイトでPMを担当しているPPです。 昨今、ベトナムの関連企業へスポットで開発を依頼する機会が増えています。ベトナム開発チームは非常に高い技術力と圧倒的なスピード感を持っており、こちらの要求に臨機応変に応えてくれる非常に心強い存在です。 しかし、海外リソースとの連携において多くの担当者が直面するのが「コミュニケーションと品質の壁」ではないでしょうか。 特に私たちが頭を悩ませたのが、ベトナム開発チームの「確認をせず、思い込