Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

コンテキストエンジニアリングについて LLM(大規模言語モデル)の分野で、最近「コンテキストエンジニアリング(Context Engineering)」という言葉が多く使われるようになりました。AIエージェントの文脈でも使われることが多く、自分の中でずっとモヤモヤしていたのですが、少し自分なりに整理してみたのでここに書いてみます。 半分以上お気持ちというかポエムや私見が混じっていますので、学術的な定義の厳密性より、自分が普段使っていて感じる実践目線での一つの考え方として捉えてもらえるとありがたいです。 「プロンプトエンジニアリング」から「コンテキストエンジニアリング」へ そもそも「コンテキストエンジニアリング」って何?「プロンプトエンジニアリング」と何が違うの?というところから始めたいと思います。 プロンプトエンジニアリングは、ものすごい単純にした図にすると以下になると思います。 プロンプ
Claude Code で開発効率 85%UP!AI との往復を 20 回 →3 回に減らす実践テクニック 🎯 この記事で得られる成果 ⏰ 読了時間: 約 10 分 🎯 対象読者: Claude Code/Cursor/GitHub Copilot 使用者 📊 実証データ: GitHub PR 実例あり(53 分で実装完了) 💡 実装難易度: ★★☆☆☆(初中級者でも実践可能) 具体的な改善効果 AI との往復回数が平均 85%削減(私の実測値) コード修正時間が 75%短縮 CI/CD エラー率が 90%低下 実際に私がこの個人プロジェクトで実践し、通常 20 往復以上かかる実装を 3 往復で完了させた手法を公開します。 ‼️【2025/08/13追加】Claude Code・AI駆動開発の関連記事 😩 あなたもこんな経験ありませんか? 「AI を使えば開発が楽になる」そう思っ
この記事のターゲット快適な開発環境のメリットを知らない経営者やエンジニアの方々に向けて書いています。 この記事の目的Claude CodeなどのAIを活用したコーディングエージェントを最大限活用するには、まず「快適な開発環境」という土台が必要です。その重要性と構築方法をお伝えします。 この記事を書いた背景最近、いろいろな会社のプロダクトの状況を見る機会が増えています。 とりあえず一旦見てほしいみたいなものや技術顧問、アドバイザー的な立場で関わることもあるのですが「非常にもったいないな」と思うことが多いです。 色々な会社を見ていると、 テストが書かれている、CIが回っている、デプロイが自動化されている みたいなプロダクトは実は少数派で テストはない。CIが常に壊れている。デプロイは手動でやっている みたいなプロダクトが多いことにびっくりしてる — すてぃお (@suthio_) August
Linuxの創造主、Linus Torvalds氏が、Googleのエンジニアから提出されたRISC-V関連のコードを「ゴミ(garbage)」と一蹴し、プルリクエストを却下した。この出来事は、オープンソース界の巨頭が、品質と規律に対する揺るぎない姿勢を改めて示したものとして、大きな波紋を呼んでいる。 静寂を破った「ゴミ」発言 事件が起きたのは、Linux 6.17カーネルのマージウィンドウ(新機能を取り込む期間)が閉じようとしていた2025年8月8日金曜日のことだ。GoogleのAndroidチームに所属するエンジニア、Palmer Dabbelt氏が、次期カーネル向けのRISC-Vアーキテクチャ関連の機能追加を求めるプルリクエストを提出した。 これに対し、週末にかけてTorvalds氏から返されたのは、彼の代名詞とも言える、率直かつ痛烈な拒絶の言葉だった。Linuxカーネルメーリングリ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Context7、Serena、Cipher で得られるメリット 開発効率の大幅な向上 Context7:最新のAPIドキュメントを自動取得し、古い情報によるエラーを防止 Serena:IDEレベルのコード理解により、大規模リファクタリングを効率化 Cipher:過去の解決策を記憶し、同じ問題への対処時間を削減 コスト削減効果 ツール利用料0円:すべてオープンソースツール 注意:Claude APIやOpenAI APIの使用料は別途発生します API使用量の削減:Cipherのメモリ機能により、重複する質問を回避 デバッグ時間の短縮:
プロダクト開発をしていると、ユーザーや社内から改善要望をもらうことがよくある。でも、その要望の多くが「How」しか書かれていなくて、本当に必要な「Why」が書かれていない。 例えば、よくあるものだと 「ユーザー一覧をCSVでダウンロードできるようにしてほしい」 「検索結果を50件ずつ表示してほしい」 「削除ボタンを赤色にしてほしい」 といったものだったりします。 社内の人には「HowはあってもなくてもいいのでWhyを書いてください」と言っているんだけど、実際にWhyが書かれているケースは少ない。 テンプレートみたいなものを用意してもひどいケースだと「◯◯機能がほしいので◯◯機能を作ってください」みたいなことが書かれている。 どうしてWhyが重要かというと、"最適な解決策を見つけつつ、将来の拡張性も考慮した設計にしたい"からです。 このnoteではなぜ、要望にはWhyが重要でHowが重要では
Claude Codeを活用し、仕様駆動開発を実現するためのプロセスと工夫を解説。チーム開発で起こる「存在忘却」「タイムループ」「記憶リセット」などの課題を、AI-DLCやKiroのSpecs・Steering手法を参考に解決するアプローチを紹介。要求定義、詳細設計、タスク分解を厳密な記法や推論モデルで…
はじめに ご無沙汰しております。Cursor→Claudeとコスって開発PMを日々やっている中で、何を発信してよいやら迷走した1ヶ月でしたが復活しました。結局のところ、Tipsとプロンプトかなあというところに思い至りまして、そのまま使えずとも、「こんなことに使えるんだあ」という気付きになれば幸いです。 Claudeと言いつつ、ChatGPTでもGeminiでも行けるっちゃいけるんですが、Opusがやっぱり優秀なのでClaudeでやっています。 概要:ワークフロー図づくりで“詰む”前に── 「フロー図描いてって軽く言われたけど、そもそも何を聞けばいいんや……」――そんな若手の悲鳴を(また)聞きまして、プロンプトで一撃解決できんかと作ってみました。 「プロンプトはそのまんま載せてます。コピペして即生成AIに突っ込めば動くはず。 こんな感じのフローが簡単に作れるはずです 目次 なんでプロンプト?
職場で飛び交う「いってこい」「正直ベース」「ガラガラポン」などの言い回し。そうした“おじさんビジネス用語”たちを、あえて使う必要はどこにあるのでしょうか。 「おじさん」というキャッチーな表現の裏側に、実は深い仕事哲学や仕事観が隠れていたりしないだろうか……? 言葉使いという切り口から、上司や先輩のマインドセットに迫れないだろうか……? そんな仮説のもと、「おじさんビジネス用語」の特徴から用法、付き合い方を言語学者の川添愛さんに考察していただきました。 著者:川添 愛1973年生まれ。九州大学文学部卒業後、同大学大学院にて博士(文学)取得。2008年、津田塾大学女性研究者支援センター特任准教授、12年から16年まで国立情報学研究所社会共有知研究センター特任准教授。現在は作家としても活動している。著書に『言語学バーリ・トゥード(〈Round 1〉〈Round 2〉)』『働きたくないイタチと言葉
1 年以上前から、チームメンバーの提案で Container/Presentational パターンを現代的にアレンジした設計を導入し、徐々に改良を重ねてきました。 Hooks が普及して、関数コンポーネント内で状態管理や API 呼び出しができるようになって便利になった一方で、いくつかの困りごとがありました。 「見た目だけテストしたいのに、なんで API モックの準備が必要なんだろう...?」 「このコンポーネント、何の責務を持ってるんだっけ...?」 「新しいメンバーが入ったとき、どこを変更すればいいか分からない...」 確かにファイル数は Hooks だけの時より増えてしまいますが、責務分離により各ファイルが単純になり、特にチーム開発では「単純明快なルール」の方がうまく機能することが分かってきました。 そこで、一時期「もう古い」と言われがちだった Container/Presenta
最近、Claude Codeを使っている人から「レビューが追いつかない」という相談をよく受ける。これは偶然ではなく、必然的に起きる現象だと考えています。 このnoteでは どうしてClaude Codeによる生産性向上の限界が訪れるのか どうすれば、全体の生産性が向上するのか Claude Codeを利用した場合にレビュープロセスでのボトルネックをどのように解消させていくか の3つを書いていきます。 プロダクト開発の典型的なワークフローまず、多くのチームで採用されている機能追加のワークフローを整理してみる。 ※あくまで一般例なので、チームにより変更があると考えています 機能追加のワークフローこの流れ自体は理にかなっていると思っています。 問題は各プロセスの処理速度のバランスです。 ボトルネック理論で考える開発プロセス生産管理の世界には「制約理論(TOC: Theory of Constra
7月25日、Jono Alderson氏が「It’s time for modern CSS to kill the SPA」と題したブログ記事を公開し、海外で話題を呼んでいる。 7月25日、Jono Alderson氏が「It’s time for modern CSS to kill the SPA」と題したブログ記事を公開し、海外で話題を呼んでいる。 この記事では、モダンCSSとブラウザ標準機能がシングルページアプリケーション(SPA)の利点を置き換え、マルチページアプリケーション(MPA)への回帰を促す潮流について詳しく紹介されている。以下に、その内容を紹介する。 「アプリのように見せたい」思考の罠 従来、サイトを“アプリらしく”見せる最も手軽な手段はSPA (Single Page Applications)だった。ReactやVueを使い、クライアント側でルーティングと描画を担
Intro 筆者のように、インターネット上での生活が長く、かつエンジニアとして生きてきた人間には、一般の人には伝わりにくいデジタルの遺品が多く存在する。 仮に自分が死んだ場合に、これらをどのように遺族に処分してもらうかは、なかなか難しい問題だ。筆者はこの「デジタル終活」をどうするかを、長いこと模索してきた。 今回は、「1Password」と法務局が行う「自筆証書遺言保管制度」を用いた方法を思いついたため、検証を試みる。 注意 筆者はエンジニアであり、法律の専門家ではない。 本方式は、法的に有効な遺言の作成については範囲外である。 本方式の目的は、「遺族の負担を減らす」ことである。 ここで「デジタル 遺品」とは以下のようなものを指す。 自分が使ってきたメールアドレスや SNS のアカウント 取得しているドメイン 登録しているサブスク 管理しているコミュニティや OSS etc. 以下のような
本記事は AWSアワード受賞者祭り 6日目の記事です。 ✨🏆 5日目 ▶▶ 本記事 ▶▶ 7日目 🏆✨ こんにちは、玉邑です。 年齢を重ねるにつれて、睡眠時間が翌日のパフォーマンスに大きく影響することを実感するようになりました。よく眠ることの大切さを、改めてしみじみと感じています。今回は、そんな貴重な睡眠時間をしっかり確保するための工夫についてお話しします。 ITシステムの運用に携わっている方であれば、夜間や休日のオンコール*1対応を経験されたことがあるのではないでしょうか。 私自身も、15年以上前にシステム運用を担当していた頃は、連日鳴り止まないオペレーターからの電話に疲弊していました。 当時はシングル構成のサーバーが多く、可用性を高める仕組みの成熟度もまだ低かったように思います。 現在のIT技術では、可用性を高めるための仕組みが非常に洗練されています。 たとえば、AWSのマルチAZ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く