本記事は2026年4月25日時点で公開されている情報に基づきます。事件の最終的な影響範囲・攻撃手法の詳細は今後の公式発表で更新される可能性があります。 はじめに 2026年4月24日、クラウドファンディング国内最大手の 株式会社CAMPFIRE が、最大 22万5846人分 の個人情報が漏えいした可能性があると発表しました。プロジェクト実行者の口座情報や支援者の住所など、極めてセンシティブな情報が対象です。 事件の起点は GitHubアカウントへの不正アクセス。「GitHubが侵害されただけでなぜ顧客情報が？」と思った方は多いのではないでしょうか。本記事では、公開情報から事件の経緯と攻撃の流れを整理しつつ、エンジニアとして組織を守るために今すぐ見直すべきポイントをまとめます。 何が起きたか — タイムライン CAMPFIREが段階的に公表してきたプレスリリースをもとに、時系列を整理します。

はじめに 最近、AI エージェント（GitHub Copilot / Claude Code / Cursor / OpenCode / Codex …）に渡す「指示書」の種類が一気に増えました。 GitHub Copilot → .github/instructions/*.md, .github/prompts/*.md Claude Code → .claude/commands/*.md, .claude/agents/*.md Cursor → .cursor/rules/*.mdc これに加えて MCP サーバー / hooks / skills … チーム内でこれらを 「どこから集めて、どこに配っていますか？」 絵にすると、複数の取得元 × 複数のハーネス という多対多の配線を、各チーム／各リポが自前で組んでいるイメージです。 個々のツールが便利になっても、チーム全体としてこ

みなさん、Conding Agentの Instructions, Skills, Agents, Prompts...色々とどう管理するか迷っていませんか？ 今回それらを管理するためにMicrosoftから生まれたこちらAgent Package Manager。 そしてもうひとつ、Skillに特化して GitHubが public previewした gh skills。 今日はこの二つをとにかく触ってみようと思います。 ちなみに体系的にまとめられた内容を知りたい方は、これらの記事がとても良かったです！ こちらの記事を読んで理解された方は続きを読まなくて大丈夫だと思います。 ただ、私これを読んでもまだわからないことがありました。 まだまだ初級エンジニアです。 この先はとりあえずコンテキスト作って、 とりあえずスクショ貼りまくって、 不器用戦法で触りまくって理解してやろう！、という泥くさ

AIエージェントを使い始めると、ほぼ全員がぶつかる壁があります。 「エージェントがコンテキストを理解してくれない」 Claude Code、Cursor、GitHub Copilot、OpenCode。 どのツールも、適切な指示（コンテキスト）を与えないと真価を発揮しません。 近年、この「エージェントに適切な装備を与える」作業をハーネスエンジニアリングと呼ぶようになりました。 しかし現状は、以下のような課題があります： .cursorrules をプロジェクトごとに手書き .claude/commands をコピペで共有 MCPサーバー設定をWikiにまとめる チーム間で設定がバラバラ これらを統一的に管理する方法がありません。 本記事では、この課題を解決する APM（Agent Package Manager） を紹介します。 APMとは 一言でいうと 「AIエージェント設定のnpm」

git alias を使ってコミットメッセージをAIに書かせる 最近はこれを git alias に入れて、コミットメッセージをゼロから書くことがほぼなくなりました。 aicommit = "!f() { COMMITMSG=$(claude --no-session-persistence --print 'Generate ONLY a one-line Git commit message in English using imperative mood. The message should summarize what was changed and why, based strictly on the contents of `git diff --cached`. DO NOT add an explanation or a body. Output ONLY the com

Oracle Étudeを“データベース構造”として読む──Link-Like SystemはなぜOracleなのか [蓮ノ空システム論#2] これまで「Oracle」という語は、 神託 予言 観測ログ システムログ として解釈されてきた。 だが、もう一つの意味がある。Oracle Corporation が提供する「Oracle Database」という文脈だ。 データベースとは、情報を単に保存するのではなく、変更履歴ごと管理する仕組みである。 Oracle Étudeの語りは、出来事の断片ではなく、更新の連鎖として提示され、“状態”よりも“変化”を語る。 この視点を拡張すると、Link-Like Systemは一種のデータベース的世界として理解できる。 キャラクターの行動、ライブ、配信、そしてファンの応援やコメント──それらはすべて、世界を更新するトランザクションとして振る舞う。 推し

「持ち家を賃貸に出すってどうなんだろう？やっぱりリスクが大きいのかな？」 「持ち家を賃貸したい場合、最初に何から始めればいいのか知りたい」 「失敗しないで持ち家を賃貸に出す方法や進め方を、しっかりと順番に理解したい」 持ち家を賃貸に出したいと思っても、さまざまな不安を感じる方は多いのではないでしょうか。 結論からいうと、持ち家を賃貸するには「収入が得られる」「建物が劣化しない」などのメリットがある一方で、「費用もかかる」「入居者トラブルが起こることもある」などのデメリット・注意点・リスクも存在します。 ただし、こうしたデメリットや注意点、リスクは、対策しなかった場合に起こるものであり、それぞれのステップごとにしっかりと準備・対策すれば、防ぐことが可能です。 この記事では、持ち家を賃貸する場合の基本知識やメリット・デメリット、そして、「失敗せずに持ち家を賃貸するための9ステップ」を整理して、

普段業務で色々なデータベースを触っていると、こいつの中身はどうなっているんだろうと気になることがあります。そんなわけでDatabase Design and Implementation: Second Editionという書籍をもとに、Go言語でRDBMSを自作しました。本書はJavaで書かれていますが、そのまま写経するのは面白くないのでGoでリライトしています。 出来上がったもの: github.com CREATE TABLE / INDEX / VIEW、SELECT、INSERT、UPDATE、DELETEといった基本的なSQLが実行できます。書籍では終盤GROUP BYやクエリ最適化をする章がありますが、まだ手を付けておらずインデックスまでの実装となっています。 なおAIコーディングエージェント全盛期ですが、この実装は学習目的なのでAIの利用は控えめにしました（テストとかでは使

全くゲーム開発をしたことがない私が、たった11日間、スキマ時間にほぼスマホから指示を出しただけで、ゲームを作ることができた。 そのゲームがこれだ。 実際にプレイしてみてほしい。 gacha-survivor.sho-shimauchi.workers.dev 以下はPC版のスクリーンショットだが、モバイルにも対応している。 国際化対応もしていて、英語や中国語など8か国語でもプレイ可能だ。 ゲームとして面白いかと言われると微妙だろう。 レイアウト崩れなどのバグもまだまだある。 しかし、単なる思いつきをここまで形にできるなんて想像もしなかった。 Claude Code + Opus 4.5 は、ITエンジニアのライフスタイルを激変させるほどの革命的なプロダクトかもしれない。 ちょっとした新機能などにも「革命的」なんていう宣伝文句が乱発されるようになった昨今、「革命的」などと言ってしまうと返って

🚀 忙しい人のためのDuckDB 3行要約 「分析版SQLite」: pip install duckdb するだけで使えるサーバーレスなDBでありながら、大量データの集計に特化した圧倒的な性能を持つ。 インポート不要のクエリ: CSVやParquetファイルをDBに取り込む手間なく、そのままSQLで分析・集計が可能。 データ分析の万能ナイフ: ログ集計、ETL処理（データ変換）、大規模データの探索など、エンジニアの「手元の作業」を劇的に速くする。 ⏱️ クイックスタート（コピペで即座に集計） Python環境があれば、DuckDBだけで今すぐ実行できるサンプルです。 import duckdb # 1. 100万件のテストデータを一瞬で生成して集計 # サーバー不要で「100万件」を0.1秒以下で扱えるのがDuckDBの魅力です result = duckdb.sql(""" SELE

はじめに PostgreSQL記事の入門編はこちら 入門編では、インデックスの効き方やN+1問題といった、明日からすぐに使えるコードレベルの改善に焦点を当てました。 しかし、サービスが成長し、データ量が増え、多くのユーザーが同時にアクセスするようになると、単なるSQLの書き方だけでは解決できない課題に直面します。 「テスト環境では動いていたのに、本番で謎のデッドロックが起きる」「データが増えすぎてバッチ処理が終わらない」「コネクション数が溢れた」……。 今回は初級編として、そうした壁を乗り越えるための、アーキテクチャやDB設計、運用まで踏み込んだ10個のTipsを紹介します。 開発者が「SQLを書くだけ」から「DBを設計・運用する」視点へとステップアップするための、転ばぬ先の杖となれば幸いです。 【Section 1: データ設計とスキーマの工夫】 「とりあえず動く」から「スケールしても耐

方法3: Web版 2025年10月、Claude Code Web版がリリースされた。 https://claude.ai/code claude.aiにログインし、GitHubリポジトリを接続するだけでいい。ターミナルの知識は不要。GitHubとの連携は必要だが、外出先でスマホからもアクセスでき非常に便利だ。 初期設定適当なフォルダを作って起動。起動したら、まずはフォルダに移動して /init コマンドを実行してみよう。プロジェクト構造に基づいたCLAUDE.mdファイルが自動生成される。これがClaude Codeとの最初の対話になる。 Part 5: 基本操作とショートカットキーボードショートカット覚えておくべきショートカットは限られている。 Enter: メッセージ送信 Shift+Enter: 複数行入力 Tab: 思考表示のトグル Esc: 現在の操作を中断 Esc Esc:

この記事では、複数のAIエージェントを組み合わせた開発フローと、それを支える環境構築のTipsを紹介します。 私はClaude CodeやCodexといったAIエージェントを毎日使っています。ただ単体で使っているとどうしても「このAIの判断、本当に正しいのかな？」と不安になることがあります。 そんな課題を解決するために試している「Claude CodeからCodexを呼び出してクロスチェックする」というフローを紹介します。 Claude Codeは非常に優秀で、実装からレビューまでこなしてくれます。ただ同じセッションで繰り返し確認を求めても、同じ視点からの回答になることはありませんか。 ここに課題があります。 毎回、何回聞いても同じ視点からの回答になる 局所解に落ちても気づけない 違う視点が欲しくなる 人間の開発でも、自分で書いたコードを自分でレビューするより、別の人にレビューしてもらった

今回は、OpenAIが2026年1月に公開した「8億人のユーザーを抱えるChatGPTが、どうやってPostgreSQL（ポスグレ）をスケールさせているか」という記事が非常に示唆に富んでおり、エンジニアにとって「基本の大切さ」を再確認できる内容だったので、その要点を分かりやすく解説します。 「世界トップクラスのAI企業だし、何か聞いたこともない特殊な分散データベースを使っているのでは？」 そう思う方も多いかもしれません。 しかし、彼らのコアシステムは驚くことに 単一のPostgreSQL（シングル構成） で動いています。 なぜそのような構成で、これほどの大規模トラフィックを捌けるのか？そのアーキテクチャと運用戦略を紐解いていきます。 3行でわかる要約 基本に忠実: 複雑な分散DBを使わず、「1台の書き込み用DB + 50台の読み込み用DB」というシンプルな構成を採用。 書き込みの工夫: 書

AIエージェントがPostgreSQL対応の優れたコードを書けるようになるAgent Skill「Postgres Best Practices」、Supabaseが公開 PostgreSQLをベースにしたBaaS（Backend as a Service）の「Supabase」を開発し提供しているSupabase社は、AIエージェントがPostgreSQLに対応した優れたコードを書けるようになるAgent Skill「Postgres Best Practices」を公開しました。 We're launching a new series of Agent Skills focused on Postgres Best Practices These skills will empower your AI coding agent to produce top-notch, accura

はじめに｜RAGは検索以前に、もう壊れている 多くのRAGは、検索やEmbeddingの改善以前に、「入力データの時点で精度の上限が決まっている」。 にもかかわらず私たちは、検索精度・Rerank・評価指標ばかりに目を向けてきた。 だが実際には、RAGに渡されるドキュメントはすでに構造を失ったテキストになっている。 これまでのRAG改善は「正しかった」 これまでの連載では、質問設計（HyDE）、検索戦略（Hybrid Search）、Rerank、評価（RAGAS / Langfuse）など、 RAGに対して取り得る改善策や設計パターンを検証してきました。 これらはすべて、検索精度や回答品質を高める上で間違いなく有効なアプローチです。 しかし、それらを十分に実施していたとしても、ある地点から「改善しても差が出なくなる」状態に直面するケースがあります。 精度が頭打ちになる境界線 ドキュメント

OracleがもっていたソートアルゴリズムのUS7680791B2特許が昨年11月28日で期限切れとなり開放されました。 US7680791B2 - Method for sorting data using common prefix bytes - Google Patents この記事で紹介されていた。 Expired Oracle Patent Opens Fast Sorting Algorithm to Open Source Databases - InfoQ この記事で、「特許が詳細なのでAIに入れたらすぐ実装できる」みたいなことを書いてあったので、試しにClaudeさんに渡してみたらすぐ実装してくれた。 一応ソースのリンクは貼っておいたけど、自分で試してみると楽しいと思う。あと、解説も軽く書いたけど、リンク貼ってAIさんに聞くほうがいいと思う。 アルゴリズムとしては次の3

Another year passes. I was hoping to write more articles instead of just these end-of-the-year screeds, but I almost died in the spring semester, and it sucked up my time. Nevertheless, I will go through what I think are the major trends and happenings in databases over the last year. There were many exciting and unprecedented developments in the world of databases. Vibe coding entered the vernacu