Scraps 最終更新 2026/10/02 04:30

企業テックブログまとめ

@しんや /

[レポート]Sigma って何?ハンズオンで理解しちゃおう! && 日本の Sigma ユーザーによるLT大会!を開催(&LT登壇)しました

  • Sigmaユーザー会イベントでSigmaのハンズオンとユーザーの実践事例が紹介された
  • SigmaハンズオンではSigma Publicを使った実践的な操作が、LTではTerraform ProviderやCLIの活用、業務アプリ構築の事例が取り上げられた
  • Sigmaのガバナンスや運用においてTerraformやCLIの導入が課題となるため、開発環境の設定に注意が必要

@y_nakahata /

Nuxt.js から Next.js へ ── フロントエンド技術リプレイスにおけるハーネスエンジニアリングと理解負債

  • Nuxt.js から Next.js への技術リプレイスでハーネスエンジニアリングと開発フローのスキル化を進めている
  • ルールディレクトリの構成、コンテキストのドキュメント作成、開発フローのスキル化、UI比較の自動化
  • 現行システムに触れる時間やモックデータの準備、移行元コメントの活用で理解負債を解消している

@川田涼太 /

2026年エンジニアが押さえておきたいAIの「今」と「これから」

  • 2026年のAI技術は「生成」から「推論・行動」へのシフトが進んでいる
  • エージェント型AIの設計思想が標準化され、LangChainなどのフレームワークが活用され、コストと運用の視点が重要になる
  • AIの得意不得意の差が大きく、実務ではコストと運用の視点が不可欠で、モデルの使い分けが求められる

@Kou /

「知らないと損する!S3コストを55%削減するストレージクラスの罠と使い分け」~【aws】今週の人気記事TOP5(2026/09/06)

  • S3ストレージクラスをフォルダごとに使い分けることでコストを55%削減した事例が紹介される
  • Intelligent-Tieringの監視コストとGlacier IRの使い分け、移行時のリクエストコストの見積もりが具体的に説明される
  • アクセス頻度に応じたストレージクラス選択がコスト削減の鍵で、過度な自動化に注意が必要

@Yutaka Kashiwabara /

GPT-6 AstraのPrompt Cacheを実測 — 呼び出し元リージョンを変えてもcache hitを確認

  • GPT-6 AstraのPrompt Cacheが呼び出し元リージョンを変えてもcache hitを確認
  • Prompt Cacheのキャッシュエントリがエンドポイント・リージョン・API・Guardrailsの有無で再利用可能、reasoning.effortは初めて指定した値でcache write、同じ値でcache read
  • クロスリージョンでもcache readが成立し、input単価が90%低下するが、Implicit Prompt Cachingはbest effortでcache hit保証なし

@sikeda107 /

頑張りすぎない Google Cloud IAM 設計:フォルダ・グループ・PAM で始める権限管理

  • Google Cloudの権限管理をフォルダ・グループ・PAMで簡略化する設計を提案
  • フォルダごとにGoogleグループを作成し、Terraformでメンバーを管理。PAMでロールを付与し、常時付与するIAMロールを限定する
  • 常時付与するロールは組織・フォルダレベルで最小限にし、データ本体の読み取りはPAMで制限する

@Yuta NAKATA /

エンジニアサマーインターンシップ2026を開催しました

  • ウェザーニュースが2028年卒向けにエンジニアサマーインターンシップを開催し、気象データと生成AIを活用したAIエージェント開発を実施した
  • WxTech APIとMCPサーバーを活用した気象データ取得、Claude CodeとGeminiを前提とした開発、LangGraphとVue3を用いたエージェント構築
  • 生成AIの活用はコード作成速度より「作りたいものを言語化する力」が重要とし、データ利用時のルール確認が必須であることが強調された

@まちゅい /

TypeORM → Prisma 移行を、AI エージェントに任せられる形に設計した話

  • TypeORMからPrismaへの移行をAIエージェントに任せられる形に設計した
  • ハイブリッドテストで移行前後のテスト観点を同一にし、1メソッド=1PRのルールを明文化、親ブランチと統合ブランチでレビュー待ちでも進捗を維持
  • 移行中のテスト観点の変更をdiffで確認できる仕組みを採用し、PRの粒度を1メソッドに固定することでレビュー負荷を最小化する

@GENDA 公式アカウント /

数値と対話で見直し続ける生成AIツールの運用設計

  • 生成AIツールの運用は数値と対話で見直し続ける仕組みを構築している
  • 利用実績と契約データを可視化し、利用者の声をヒアリングしてツール選択や利用枠を調整している
  • 利用量の変化や上限到達をきっかけに利用者と対話し、ツールの選定や契約を見直す判断材料になる

@KenshoTakizawa@ベスト69元ゴルファーのエンジニア /

RAGの精度は「データ」で決まる — Contextual Retrievalを実測したら1位正解率が36%→100%になった

  • Contextual Retrievalを導入すると検索の1位正解率が36%から100%に改善した
  • チャンクの先頭にLLMが文脈を追加して索引化、検索精度向上とトークン削減が同時に実現
  • 検索精度向上は入力トークン数の削減に直結し、APIコストを下げることができる

@wfukatsu /

AIと帳票デザイナを作った25日(3)todos/ 280枚のレビュー在庫

  • コードレビューの在庫を280枚のMarkdownファイルで管理し、状態と優先度を明記することで課題の可視化と優先順位付けを実現
  • 1ファイル1指摘のフォーマットで選択肢A/B/Cを提示し、人間が採否を判断、複数のレビュアーが異なる観点から指摘
  • 連番で束ねてPRにまとめることでコンフリクトを減らし、解決した課題はdocs/solutionsに具体例とともに記録

@ケーエス /

【モバイルアプリ】気づかれないほうが、成功。 ― 見えないUX配慮の話

  • モバイルアプリでユーザーに気づかれない配慮として、プッシュ通知のプレパーミッションや高セキュリティ認証の対応、全額出金の注意喚起などを行った
  • プッシュ通知の許可前にはメリットを提示するダイアログを表示し、認証エラーの種類に応じた対応とリンクを設置、全額出金時は視覚的な注意喚起と共通ヘルパーを活用
  • ユーザーが誤操作を防げるよう、連打防止の共通ガードを導入し、通信の整合性を保つためのAPI統合を実施した

@日下部 聡久 /

テスト「以外」のQA活動を全部並べてみた

  • QA活動はテスト実行以外にも要件レビュー、設計レビュー、リスク評価、メトリクス活用などがある
  • 要件レビューで曖昧な仕様を防ぐ、変更リスク評価で重点テスト箇所を特定、メトリクスで品質傾向を可視化
  • バグ分析から傾向蓄積までを回すことで同じ失敗を繰り返さない仕組みを構築できる

@dach /

どこまで見る? AIレビューとCIが通ったあとの人間レビューを3段階で決める

  • AIレビューとCIの結果をもとに人間レビューの深さを3段階で判断するフローを紹介
  • Level1はPR内で判断が閉じる、Level2は後続確認を残す、Level3はPR外の根拠を調べる
  • AIレビューの条件やCIの結果が揃っていればLevel1で終わる、後続確認が必要ならLevel2、PR外の根拠が必要ならLevel3に分ける

@szka07 /

モブプロにAIを加えたら人間には疲れる仕事だけが残ったので、AI前提の役割分担を模索している

  • AIを含めたモブプロでドライバー交代時のコンテキスト引き継ぎや待ち時間が課題となった
  • AIアカウントのコンテキスト引き継ぎにファイルを活用、AI作業はモブセッション外に回すことで待ち時間を短縮
  • AIアカウントを複数人で共有できない制約により、ドライバーとナビゲーターの役割が曖昧になる

@takeuchi_kazuya /

別アカウントの API Gateway を Lambda から呼ぶ方法を 2 パターン試してみた

  • AWSのクロスアカウント間でLambdaからAPI Gatewayを呼び出す2つの方法を実装例とともに解説
  • リソースポリシー方式とAssumeRole方式、REST APIとHTTP APIの違い
  • HTTP APIではリソースポリシーが使えないためAssumeRole方式が必要で、呼び出し元のアカウント情報が異なる

@まっさん | TOKIUM /

正解データを作らない、簡単なevalの作り方

  • Claude Codeの品質改善にevalを活用し、ログを元に失敗を観測して改善するプロセスを紹介
  • ログを自動収集して失敗を分類・数えることでevalを作成し、発動率を52%から78%に向上
  • evalは正解データを用意せず、実際の失敗を観測して作成するべきで、発動すべきでないケースも評価に含める