アーキテクチャ設計の階層モデル - kawasima
ビジネス目標、非機能要求から具体的な技法、ツールまでの意思決定を階層を分けて整理する。 table:アーキテクチャ設計の階層モデル 層 名称 例 L0 ビジネス目標 24時間365日のサービス提供を実現する L1 非機能要求 サービスの年間稼働率を99.99%にする L2 品質特性 可用性 L3 戦術 異常を検知する L4 技法 ヘルスチェック L5 ツール Prometheus Blackbox Exporter 教科書通りにやれば、ビジネス目標(L0)から順々に検討していって、最終的に具体的なツール(L5)を選定しようということになる。 だが、順々に検討していくアプローチは、あくまで「ひとつの子要素は必ずひとつの親要素に帰属する」というツリー構造を前提としている。実際には、以下のように多対多の関係が常に発生するため、単純なツリー分解だけでは全体像を正しく捉えきれない。 技法(L4) →
「読解をミスった時点で“戦”に負ける」ホスト指導者“軍神”こと心湊一希が、小3国語ドリルを推す理由 | 女子SPA！ | ページ 2
――山本裕典さんのホストとしてのポテンシャル、ホスト業にフルでコミットしたらどこまで昇れそうですか？ 軍神：ポテンシャルはめちゃくちゃ高いです。毎月1,000万、年間1億2,000万は普通にいきます。これは全然余裕で。ここからどこまで上がるかは未知数。そこからは彼の努力しだいかなと。 ――具体的にどんなところが優れているのでしょうか？ 軍神：彼の何が優れているかといったら“読解力”なんです。言われたことをちゃんと理解して、修正ができる。あれは相当努力してきた人じゃないと身につかない。俳優業をしてきたなかで磨かれた部分なんじゃないかと思います。読書家ですしね。 ――軍神の指導のなかでも“読解力”はキーワードですよね。ホスト力と人間力を磨く“軍神合宿”も、国語ドリルをさせる勉強法も読解力を磨くためですし。 軍神：すべての入り口は読解です。ここをミスったらすべてが終了する。読解力をつけることが最
もやもやを開きあうふり返りによって組織に生まれる変化とは／ふりかえりカンファレンス2024
チームで"もやもや"を共有しあうふり返り手法KMT（Keep/Moyamoya/Try）、"もやもや"を問いに変えるKMQT（Keep/Moyamoya/）のやり方ややる時のポイント、このふり返りをやると何がいいのか？やってみた経験をふり返りながら考えたことを紹介しました。 ふりかえりカンファレンス2…
AI 駆動の業務変革手法 :「課題は何ですか？」と聞くのをやめた日 | Amazon Web Services
提案を始めると、生成 AI による成果物作成の高速化と意思決定への集中に期待の声をいただき、一定の効果も実感いただけました。その一方で、見逃せない反応もいくつかありました。 AI エージェントに業務を任せるのは、BCP の観点で危険である。我々のビジネスは止まることが許されない AI BPR を実施してみたが、予想した解決策の枠内にとどまった。これまでの検討に比べて大きな進歩を感じない いずれも正当な主張に思えます。しかし、事業継続性については人間にプロセスを残しても体調不良や欠勤によるリスクがあります。止まることが許されないならば本来 AI エージェントの活用は合理的なはずです。後者は、課題と解決策について常日頃考えている担当者であれば妥当な評価です。一方、生成 AI の提案を批評家目線でとらえて共創相手として扱っていない点が気がかりでした。 表面的なフィードバックは多様ですが、深層に共
「//このコメントを消したら動かない」は大体Shift_JISの2バイト目が原因で発生する - Qiita
TL;DR Shift_JISにしただけでコンパイラが通らなくなる恐ろしい事件とその回避法について。 \ (¥)のASCIIコードは0x5c 表、能は良くない UTF-8は神 2023/12/06追記 誤りがあったので訂正します。こんな読まれると思ってなかったので正直ちょっとびっくりしていますが、いろいろコメントありがとうございました。（ツイート等全て拝見しました。） Shift_JISが悪いわけではない（デフォルトのエンコーディング設定の問題）→追記しました UTF-8にはUTF-FSSという仕様でこの問題が回避されている→マジでタメになる知識ありがとうございます OSによってデフォルトのエンコーディング設定が異なるせいで、デフォルト環境での動作がOSにより異なる→なるほど？（調査中） CRLFとLF問題では→なるほど？（調査中） そんな問題何を今更→UTF-8が出てから生まれたからです
APIエラーレスポンスを標準化する - RFC9457移行で得られる5つのメリット - Qiita
こちらはHubble Advent Calendar 2025の12日目の記事です。 はじめに 株式会社Hubbleでバックエンドエンジニアを担当している @horin0211 です。 みなさんは API を開発していて、こんな経験はありませんか？ 「このエンドポイントのエラー形式、どうなってたっけ？」 「フロントエンドから、エラーメッセージの取得方法がAPIごとに違うって指摘された...」 「新しいメンバーが、エラーハンドリングのコードを見て混乱してる」 APIのエラーレスポンス形式が統一されておらず、プロジェクトやエンドポイントごとに構造がばらつくことは少なくありません // あるエンドポイントのエラー { "error": "User not found", "code": 404 } // 別のエンドポイントのエラー { "message": "Invalid input", "e
ゼロから始めた Musubi インフラ IaC 化の軌跡 — 課題解決と工夫の記録 - KAKEHASHI Tech Blog
はじめに 対象となる読者 IaC 化を決めた背景 🏗️ 困ったこと & カウンター 課題.1 リソースの管掌範囲が明文化されていない 🤯 カウンター ✅ 課題.2 IaC ツールが乱立していた 🤯 カウンター ✅ 課題.3 デプロイ元のリポジトリが体系化されていない 🤯 課題.4 Serverless Framework の有償化 🤯 工夫したポイント 💡 Terraform ディレクトリ構成 📂 CI/CD パイプラインの並列化 ⚡ セキュリティの担保: OIDC 認証で IAM User を撲滅 🔐 drift 検出: 手動変更を見逃さない 🔍 PR のライフサイクル 🔄 Devin による Renovate PR の自動修復 🤖 今後の課題 🚀 おわりに はじめに こんにちは。 電子薬歴 Musubi の基盤開発チームで SRE を担当している大山です。 今回
LLMが生成したテストの品質をMutation Testingで検証する - KAKEHASHI Tech Blog
ランキング参加中プログラミング はじめに 「このファイルのテストを書いて」とLLMに依頼すれば、それらしいテストコードが秒で生成される時代になりました。しかし、生成されたテストが本当に役に立つかどうかは別問題です。 コードカバレッジが100%でも、アサーションが甘いかもしれない 重要な分岐をテストしていないかもしれない 人間がレビューしても、網羅性の判断は難しい 本記事では、Mutation Testingを使ってLLM生成テストの品質を定量的に評価し、改善するワークフローを紹介します。 Mutation Testingとは コードを意図的に壊し（ミュータント）、テストがその変更を検出できるかを確認する手法です。 // 元のコード function getGrade(score: number): string { if (score >= 90) return "A"; // ... }
翻訳記事「AIコーディングツールによって加速するコード生成に品質保証活動はどう立ち向かうか」 - ブロッコリーのブログ
はじめに 本記事は、Lilia Abdulina（JetBrains の QA責任者）による研究（Vitaly Sharovatovが協力）である「QA in the Age of AI-Accelerated Development」の翻訳記事です*1*2。 本記事は許諾を得た上で翻訳しています*3。 なお、本記事は現在もGitHub上でディスカッションが続けられています。記事を読んで気になった方や疑問を持った方はぜひディスカッションに参加してください！ 本記事の主な見どころ AIによって「理解の負債」だけでなく、「意図の負債」も増えている AI以前では副産物として獲得できていた「ビジネスドメインの知識」を蓄積できなくなっている 「評価」よりも「予防」に重きを置いている「積極的な品質保証活動を行う企業」と、そうではない「反応的な品質管理を行う企業」が存在する コストはO(n + εn2)
AI エージェントの未来 - OAuth にも進化が必要な理由
こんにちは、Azure Identity サポート チームの 高田 です。 本記事は、2025 年 5 月 27 日に米国の Microsoft Entra Blog で公開された The future of AI agents—and why OAuth must evolve を意訳したものになります。ご不明点等ございましたらサポート チームまでお問い合わせください。 我々は今、とてつもなく大きな変化の最初の段階にいるのかもしれません。 今日の AI エージェントは、ソフトウェア エンジニアのコード作成を支援したり、IT の運用チームによるシステムのトラブルシューティングを支援したり、さまざまな分析タスクを処理したりと、すでに目を見張る物となっています。これら特化したエージェントはより多くのことを実現できるようになりつつありますが、我々はその可能性の片鱗をまだ見始めたばかりなのです。次
メルカリのClaude Codeセキュリティ設定の組織配布戦略 - Claude Code Meetup Japan #4
https://aid.connpass.com/event/386203/
“先延ばし癖”の原因に新知見──「目標設定能力の欠如」のせいではない？ 英国チームが研究発表
2019年にスタートした本連載「Innovative Tech」は、世界中の幅広い分野から最先端の研究論文を独自視点で厳選、解説する。執筆は研究論文メディア「Seamless」（シームレス）を主宰し、日課として数多くの論文に目を通す山下氏が担当。イラストや漫画は、同メディア所属のアーティスト・おね氏が手掛けている。X：＠shiropen2 研究チームは、英国の大学生111人を対象に、短期目標（1カ月以内）と長期目標（6カ月以上）をそれぞれ挙げさせた。そして、目標に対する行動回避の可能性、達成できた場面をどれくらい鮮明に想像できるか、失敗を想像した際の予期不安など、さまざまな属性について評価を行った。 分析の結果、予想通り、先延ばし傾向が高い人ほど、短期的・長期的を問わず、目標に向けた行動を意図的に回避する可能性が高いと自己評価していることが確認された。 しかし、目標達成の場面を想像する際の
『AI時代のソフトウェア開発を考える』｜t-wadaさんご講演とWHI開発セッションの様子をお届け！｜WHI Developers Blog
2026年3月2日、Works Human Intelligence（以下、WHI）は日本のテスト駆動開発の第一人者である和田 卓人さん（以下、t-wadaさん）をお招きし、講演イベントを開催しました！ イベント前半では、t-wadaさんに『AI時代のソフトウェア開発を考える』というテーマで基調講演をいただきました。続く後半では、WHI社員による実践的なユースケースのLTや、t-wadaさんを交えたパネルディスカッションも実施。 社内会場とオンラインを繋いだハイブリッド形式で行われ、合計440名を超えるメンバーが参加する大盛況の1日となりました。Slackチャンネルでの実況も止まらず、活気にあふれた当日の様子をお届けします！ AIの「壁」を突破し、明日からのアクションに繋げるーイベント開催の目的はじめに主催であり、Technical Executiveとして開発者育成を務める山本 隼也さん
“キュピーン猫画像メーカー”初日50万アクセスもサーバ代「0円」 その秘密は
「InspirationCat」は、動物の画像をアップロードすると、AIで背景を除去して動物を切り抜き、拡大縮小・回転で調整した上で、集中線と重ねて“キュピーン”画像に編集・ダウンロードできるサービス。飼い猫のキュピーン画像を公開していた「むちゃまる（5）」（@neko_muchamaru）さんの投稿からヒントを得て開発したという。 ブラウザ完結の超軽量設計＋「Cloudflare Pages」活用 背景除去の処理には本来、サーバ上のGPUで動かすAIモデルが必要だ。「InspirationCat」では、背景除去ライブラリ「@imgly/background-removal」を通じて「ONNX Runtime Web」を利用することで、サーバではなくユーザーの端末上で直接実行した。 ONNX Runtime Webは、AI用の計算をブラウザ内のWebAssemblyやWebGPUで処理する
調査と改善、考える順番 - Konifar's ZATSU
開発の不具合調査やちょっとした改善を進める時、考えるべき"順番"がある。 タスクの粒度の差はあれど、自分はいまだに順番を間違えては無駄な遠回りをしているので雑にまとめておく。 1. 事実を確認する 誰かからの報告や予想を鵜呑みにしてはいけない 本当に起きている事実を自分で確認しにいくこと 2. 問題を理解する 結局何が問題なのかを理解せずに対応してはいけない なんとなくわかった気になることなく、何が問題かを理解すること 3. 真因を特定する なぜその問題が発生しているのかを特定せずに局所的に解決しようとしてはいけない 仮説を立ててもいいが、全体像を理解し広げて考えた上で、削ぎ落として真因を特定していくこと 4. 解決策を選択する 真因に対してたったひとつだけの思いつき解決策に飛びついてはいけない 最終的に一つに決める前に、決定軸を整理して評価し選択すること 例を一個上げると、たとえばあるジ
「誰かがやるだろう」をやめた1年間の記録 - KAKEHASHI Tech Blog
はじめに 今年は変化した一年だったなぁ。一番の変化というと個人の課題からチームの課題へと視座感が変わったところで、それまでは個人のスキルアップが目標のほとんどだったけど、チーム状況の変化を目の当たりにして今のままだとダメだなと感じ、チームの課題を自分の課題と思って取り組めるようになったのが大きな変化だった。 それによって主体的に動き・提案したり既存フローを変えたりして、これまでマネージャー層が現場の意見を聞きながら少しずつ調整かけていたものを現場の目線でいい感じに変えられるようになったし、実際手応えも感じることができた（あとは、変化したやり方がまだ浸透しきっていない感じはするので、文化として当たり前の状況にしていけるといいのだけれど） これは2025年末に、私がSlackに残したつぶやきです。 カケハシでAI在庫管理プロダクトの開発に携わっている清水（@_smzst）と申します。この記事で
axios, LiteLLM...不使用だったのでOK、ではない。「次に備える」ソフトウェアサプライチェーン侵害への対策
弊社ウェビナー ( https://flatt.tech/takumi/event/github-actions-compromise-202603 ) におけるCTO米内の講演資料です。 動画はこちら ( https://www.youtube.com/watch?v=ms8MkNmiejA )
「あいつには関わりたくない」と思われていた2年間の話をする - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 4月になった。 今年も新卒が入ってくる。ぴかぴかのビジネスバッグを持って、ちょっと緊張した顔で席につく。あの顔を見ると、毎年どうしようもない気持ちになる。 この記事は、たぶんぼくが書くべきじゃない。給湯室で「あいつに頼むと一回で済まないんだよな」と名前を出されていた側の人間だ。偉そうに「こうしろ」と言える立場じゃない。 でも書く。 あのころのぼくに、誰か一人でも教えてくれていたら。お前のその丁寧さ、全部自分を守ってるだけだぞ、と。お前が真面目にやっているつもりのそれ、周りは全部見えてるぞ、と。一言でよかった。一言あれば変われた。たぶん。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
古典ドメインモデルパターンの解脱
Beads: A Git-Friendly Issue Tracker for AI Coding Agents | Better Stack Community