2025/4/24に開催した #アーキ部 『丁度ええ! ロギング』の内容を編集したものです。 ロギングにまつわる問題の構造 ロギングにまつわる現場でよく見られる問題には以下のようなものがあります。 ロギングガイドラインを定義して、開発者に周知し実装してもらったが、実際運用してみると、役に立たないログが多すぎる。 担当者が異なると、ログ出力する粒度が微妙に異なり、解析に時間がかかる。 ログの形式や内容が統一されておらず、分析ツールでの活用が難しい。 ロギングベストプラクティスは探すといくつか見つかります。 https://www.dataset.com/blog/the-10-commandments-of-logging/ https://betterstack.com/community/guides/logging/logging-best-practices/ https://new

NEW! 2025.04.28 ITニュース 生成AIAI AI業界の競争は激しく、昨日まで最先端だった技術が、今日には陳腐化してしまうことも珍しくない。その開発の“ど真ん中”にいるエンジニアにとって、この状況は大きなジレンマだろう――。 そんなリアルを感じさせられたのが、2025年4月21日に開かれたAIベンチャー・PKSHA Technology（以下、パークシャ）による『PKSHA AI Agents』のメディア向けローンチ発表会だ。 国内ではまだバズワード感が拭えない「AIエージェント」という言葉だが、同社はすでに7000体ものAIエージェントを社会実装済みという実績を明らかにし、会場からも驚きの声があがった。 本記事では、改めて抑えたい「AIエージェントの技術的な深掘り」をはじめ、7000体投入の裏側で見えてきたAI活用におけるリアルな課題、そして「AI社員」がもたらすであろう衝

「たまに取り出せる褒め」 ふとした時に懐から取り出して、にんまりと心を温める、誰かに褒められた記憶のストック。 そんな記憶は他人のものでも、どういうわけか嬉しくなってしまうものなのである。 ※この特集はご応募いただいた「褒められたエピソード」を漫画にしたものです。 たまに取り出せる褒め　はるまきさんの場合 【作者よりコメント】 なんて良いエピソード。 慣れない街で働き始めた頃に感じた他人事のような街並みが、いつしか身近になっていく。そんな境を勝手に感じさせていただきました。 無理をして精一杯振舞うことが実はなりたい自分への王道の近道だったりするのかもしれません。私もマスターのように、はるまきさんの身の振り方を素敵だと感じました。 そしてもしかしたら知らないだけで、すました顔のあの人もあの人も、無理をして精一杯振舞っているのかも。そう考えると少し肩の力が抜ける思いです。 それにしてもバーのマ

「自閉症の長男が痴漢と勘違いされ、通報された。ショックです」。広島県内の50代の母親から、悲痛な訴えのメールが編集局に届いた。発達障害のある人が不審者に間違われるケースは少なくないようだ。当事者を理不尽に傷つけないために、対人関係やコミュニケーションが苦手な特性を理解しておきたい。 【子供の交通事故マップ】ここが危ない広島県 母親によると、トラブルはある朝、路線バスの車内で起きた。長男（21）が2人がけ座席の窓側に座っていたところ、通路側に座った中年女性が「太ももが触れるので詰めて」と話しかけてきた。だが、長男は景色を見るのに夢中。座る位置を変えずにいたところ、中年女性は「痴漢に遭った」と警察に通報した。 後日、要請を受けて母子で警察署へ。母親は、長男は名前を呼ばれなければ、自分に話しかけられていると理解できないことがあると説明した。長男のリュックサックには、要配慮だと周囲に知らせる「ヘル

こんにちは。SmartHR CEO の芹澤（@masato_serizawa）です。2025年になってから、「AIエージェント」という言葉を聞かない日はなくなりました。それまでは人間がAIに問いを投げ...

2014年から先端テクノロジーの研究を論文単位で記事にして紹介しているWebメディアのSeamless（シームレス）を運営し、執筆しています。 1週間の気になる生成AI技術・研究をいくつかピックアップして解説する連載「生成AIウィークリー」から、特に興味深いAI技術や研究にスポットライトを当てる生成AIクローズアップ。 今回は、GitHub上のリポジトリを自動的に解析し、ドキュメントを生成してくれるオープンソースAIツール「DeepWiki」を取り上げます。 ▲DeepWikiのトップページ DeepWikiはAIデベロッパーツール「Devin」の開発チーム「Cognition AI」によって開発された無料サービスです。 主な機能は、GitHubリポジトリのコードを読み取り、リポジトリ全体の解説ドキュメントページを生成することです。自然言語での説明だけでなく、アーキテクチャ図やシーケンス図

ここ1~2ヶ月でMCPについての解説がたくさん出ているしMCPが何かの説明はいらないと思うので割愛。全く何かわからない人はやさしいMCP入門を読むと良い。 こういったMCPは何か？についての記事/スライドやどのように活用するのか？の実用的な解説&紹介はすでにたくさん出ている。一方でMCPの内部について学ぼうと思った時に時にどうすればいいかというと公式のSpecificationを読むことになるはず。 ただこの入門的な解説とSpecificationの間には少しギャップがある。自分のような理解力に乏しい人間にはいきなり仕様だけ読んで「はい理解しました」とはなれない。 そこで今回はMCPのHost/Client/Serverをスクラッチで実装することを通じて、その入門とSpecificationの間を埋められると良いなと思い実装してみた。実装する言語にはRubyを使用した。 全体像 実装するの

きっかけ CursorやRoo Codeなどで関数が再生成されたりなどの問題が発生する原因を特定したかった 各プロパイダごとの情報 ※ 2025年4月26日現在の情報です 各プロパイダごとにファイルごとに何行ごとずつ読んでいるかが違います Cline: ファイルサイズで規定（300KB） Roo Code: Cline+ デフォルトが500行、行数は可変 （非公式）Claude Code: 2000行 公式ソースはないですが有志によりいくつか調査が行われているようです 都合によりソース元は省略します。 Cursor: 500行 => 250行 Codex: 最大行数は未定義、ただし実際はcontext長を超えるとエラーが出て分割依頼が出る （非公式）Windsurf: 200行（ただしシンボルで概要を把握している） Reddit Github Copilot Agent: 500行以上で要

エビデンスベースドマーケティングの手法をプロダクトマネジメントに応用する方法論 以下の前提を持つ 対象のプロダクトが という収益構造を持つこと MRR = MAU x PUR x ARPPU 対象のプロダクトが という構造を持つこと MAU = U_total x P_existing + (N_consumers - U_total) x P_new U_total: 累計ユーザー数 P_existing: 既存ユーザーがその月にアクティブになる確率 N_consumers: マーケット全体の消費者数 P_new: 未利用者がその月に新たにアクティブになる確率 対象のプロダクトの各ユーザー別の利用頻度がポアソン分布になっていること 対象のプロダクトの既存ユーザー全体での利用頻度の傾向 P_existing は負の二項分布になっていること このとき、以下が成り立つ : 一定期間における既存

はじめに 昨今、欧州や日本を中心に発展しつつある「データスペース」について、皆さんに手を動かしながら体験頂けるようなブログを書いてみます。 本記事の想定読者 ITの基礎的素養はあるけど、データスペースのことをあまり知らない方 様々な分野でデータ利活用を検討している方 そもそもデータスペースとは データスペースとは、参加する組織・企業同士が互いに信頼できる仕組みのもとで、安全かつ自由にデータをやり取りできる制度と技術基盤が整った空間のことを指します。 こうした制度・技術の構築・標準化により、業界・組織・企業間のコラボレーションを加速し、横断的な課題解決や新たなデジタルサービスの創出を支えることができます。 データスペースは、近年欧州や日本を中心に広がりを見せています。以下の図はデータスペースの概念を表しています。データスペースの各参加者は、「コネクタ」と呼ばれるソフトウェアを用いて、「カタロ

はじめに こんにちは！レバレジーズ株式会社テクノロジー戦略室SREチームの竹村です。 テクノロジー戦略室のSREチームでは、全社のエンジニアの開発生産性の向上やシステムの信頼性向上に取り組んでいます。 エンジニアの生産性向上や工数削減を叶えるため、2024年にレバレジーズの開発組織全体で、GitHub Enterprise Cloud（GHEC） への移行を行いました。 今回は、複数の施策を積み上げることで、コスト増を上回るメリットを示し、導入に至った経緯を赤裸々に皆さんにお届けできればと思います！GHEC以外のサービス導入検討の参考にもなると思うので、何か新しいサービスやプランアップを検討されているかたもご一読いただけると幸いです。 苦労したポイント！ GHEC への移行・導入にあたっての一番苦労したポイントはやはり、大幅なコスト増をまわりに理解してもらうことでした。多くの高度な機能が利

みなさんはそろそろバイブコーディングや、丁寧にプロンプトを出して、AIのタスクが完了をするのを待つことに慣れただろうか。筆者は全然慣れない。むしろAIに何を夢見たんだと毎日絶望している。 というのも、 バイブコーディングほど雑に任せることが出来ない 丁寧にプロンプトを出すにしても、だいたい毎度の同じようなプロンプトを書いている そのくせタスクは多岐にわたるので.clinerulesや.cursor/rules/に長い指示を書くことができない といった感じに、コーディング業務の一部に偏りがある。もちろんうまくAIを利用できている開発もあるが、向かないケースはとことん向かない（しかもそれが業務の柱だと泣きたくなる）。 具体的には、 サイト運用の定期的なページ追加 新規サイト制作時のテンプレート作成 のようなクライアントワークのウェブ制作におけるコモディティ化した部分なのだが、統一されたデザイン

UV Studyで登壇した資料です

明日からできる！GitHub Copilot + GitHub MCP Serverで始めるAI駆動開発 はじめに こんにちは、URBAN HACKS サーバーサイドエンジニアの池田です。 URBAN HACKSでは日々の開発でGitHub Copilotを活用しています。 コードを提案、補完してくれるだけでも十分に活躍していますが、GitHub CopilotにAgent Modeが搭載されたこと、公式のGitHub MCP Serverが登場したことにより、これらを組み合わせ、より効果的に活用できるようになりました！ この記事ではこれらを組み合わせた開発手法をご紹介すると共に、 生成コードの精度が上がりやすくなるコツ チーム開発とAIの組み合わせ方 をお伝えできればと思います！ コード生成の精度にお悩みの方や、より効果的にAIにコーディングを手伝って欲しい方の参考になれば幸いです。 G

SaaS設計レビュー 観点チェックリスト【2025年版】 SaaS設計における「レビュー観点が足りない」「属人化している」を防ぐための設計レビュー観点チェックリストを整理しました 実務でよく聞かれる質問・盲点も交えながら、設計品質を上げる観点を体系的にまとめる試みです 概要 このドキュメントは、SaaSの現場で必要と思われる設計観点を体系化したものです イベント駆動・非同期設計・マルチテナント対応・分散トランザクション・災害対策など、現代的な分散型SaaSに求められる領域を概ねカバーしていると思います 各観点は「背景・概要」「例」「よくある失敗例」「FAQ」「関連観点」によって構成されており、現実の実務に耐えるよう設計しています 🧭 Structure / DeepDive の使い分けについて 本チェックリストは観点を「Structure（構造的原則）」と「DeepDive（実装深度）」

Vibe Coding とはなんでしょうか？ はじめに提唱した Andrej Karpathy 氏はこう言っています。 参考程度に意訳をば。 私が Vibe Coding と呼んでいる新しいコーディングスタイルがあります。それは完全にバイブに身を任せ、指数関数的な変化を受け入れ、コードが存在することさえ忘れてしまうものです。これが可能なのは、LLM（例えば Sonnet を使った Cursor Composer）があまりにも優秀になっているからです。また、私は SuperWhisper を使って Composer と会話するだけなので、キーボードにほとんど触れません。「サイドバーのパディングを半分に減らして」のような、面倒くさくて自分で調べることが億劫な些細な修正をお願いします。常に Accept All を選び、差分は読みません。エラーが出たら、単にエラーのみをコピペするだけで、たいてい

2025年現在のNewSQL (最強DB講義 #36 発表資料) 2025年4月23日(水) NTTデータ OSSビジネス推進室 小林 隆浩Read less

『Software Design 5月号』の第２特集「クラス設計の鉄則」を寄稿しました。 gihyo.jp 第２特集の概要と、今回はとりあげなかった、SOLID、GoFデザインパターン、凝集度と結合度について、私がどう捉えているかを説明します。 概要 第２特集のクラス設計の鉄則は３章で構成されています。概要は次の通りです。 第1章：クラス設計再入門 モジュール性・関心の分離・依存関係を意識する 第2章：迷わないクラス設計の指針 アプリケーション開発の実践例から考える現代的な設計方針 第3章：設計の落とし穴対策 コードから問題を検知する着眼点と改善方法 第１章：クラス設計再入門 この章は、クラス設計の基礎として、ソフトウェア設計の三つの視点を紹介しています。 ソフトウェアシステム構築の基本課題として「複雑さ」と「変更容易性」に焦点を合わせ、二つの課題に取り組むための考え方として、「モジュール