nwiizo

はじめに前回の記事「RustでLinuxプロセス管理をしてみた」の続編として、今回はシグナル処理とプロセス間通信（IPC）について解説します。これらの技術は、システムプログラミングの根幹をなす重要な概念です。doc.rust-lang.orgサンプルコードはこちらに配置しておきます。github.com2025年の最新動向2025年現在、Rustエコシステムは大きな転換期を迎えています。Linux 6.13が2025年1月にリリースされ、Rustサポートが「転換点」に到達しました。また、非同期ランタイムの世界では、async-stdが2025年3月に廃止されることが決まり、Tokioが事実上の標準となっています。さらに、Rust 1.85ではasync closuresが安定化され、より表現力豊かな非同期処理が可能になりました。1. 基礎知識書籍はこちらがめちゃくちゃに詳しいのでオススメです。ふつうのLinuxプログラミング 第2版　Linuxの仕組みから学べるgccプログラミングの王道作者:青木 峰郎SBクリエイティブAmazonプロセスとはプロセスは「実行中のプログラムのインスタンス」です。皆さんが日常的に使うWebブラウザのタブやターミナルのセッションは、すべてプロセスとして動作しています。各プロセスは独立したメモリ空間を持ち、他のプロセスから直接アクセスすることはできません。これがシステムの安定性と安全性を保証していますが、同時にプロセス間でデータをやり取りする特別な仕組みが必要になる理由でもあります。シグナルとはシグナルは、プロセス間の非同期通知メカニズムです。電話の着信音のように、プロセスに「何か重要なことが起きた」と割り込みで知らせる仕組みだと考えると分かりやすいでしょう。主要なシグナルと実際の用途： シグナル  番号  用途  実例  SIGTERM  15  正常終了要求  systemctl stopで送信される  SIGKILL  9  強制終了  kill -9、OOMキラー  SIGINT  2  割り込み  Ctrl+Cを押したとき  SIGHUP  1  設定再読み込み  nginxやsshdの設定リロード  SIGUSR1/2  10/12  カスタム用途  アプリ固有の動作トリガー シグナルには重要な特徴がいくつかあります。まず非同期性という性質があり、いつ届くか予測できません。また割り込みとして動作するため、実行中の処理を中断して処理されます。そしてシンプルな仕組みで、シグナル番号以外の追加情報を送ることはできません。rust-cli.github.ioプロセス間通信（IPC）とはIPCは、独立したプロセス同士がデータをやり取りするための仕組みです。それぞれの方式には特徴があり、用途に応じて使い分けます： 方式  特徴  実際の使用例  パイプ  単方向、親子プロセス間  ls | grepなどのシェルパイプ  名前付きパイプ  双方向、無関係なプロセス間も可  ログ収集デーモンへのデータ送信  Unix Domain Socket  双方向、高速、信頼性高  Docker、systemd、PostgreSQL  共有メモリ  最速、同期が複雑  データベースのバッファプール  メッセージキュー  非同期、順序保証  ジョブキューシステム 2. シンプルなシグナル処理Ctrl+Cを検知して安全に終了最もシンプルな例から始めてみましょう。Ctrl+Cを押したときに、きちんと後処理をしてから終了するプログラムです。use std::sync::atomic::{AtomicBool, Ordering};use std::sync::Arc;use std::thread;use std::time::Duration;fn main() {    println!("プログラム開始（Ctrl+Cで終了）");        // 実行中フラグ（スレッド間で安全に共有）    let running = Arc::new(AtomicBool::new(true));    let r = running.clone();        // Ctrl+Cハンドラーを設定    ctrlc::set_handler(move || {        println!("\n終了シグナルを受信しました");        r.store(false, Ordering::SeqCst);    }).expect("シグナルハンドラーの設定に失敗");        // メインループ    let mut counter = 0;    while running.load(Ordering::SeqCst) {        counter += 1;        println!("処理中... カウント: {}", counter);        thread::sleep(Duration::from_secs(1));    }        println!("プログラムを安全に終了しました");}このコードにはいくつかの重要なポイントがあります。まずAtomicBoolを使ってスレッド間で安全にフラグを共有しています。シグナルハンドラーはいつ呼ばれるか分からないため、アトミック操作が必要になります。そしてループを抜けてから終了処理を行うことで、データの整合性を保っています。docs.rsgithub.com複数のシグナルを処理実際のサーバーアプリケーションでは、複数のシグナルを適切に処理する必要があります。use signal_hook::{consts::signal::*, iterator::Signals};use std::{error::Error, thread, time::Duration};fn main() -> Result<(), Box<dyn Error>> {    let mut signals = Signals::new(&[SIGTERM, SIGINT, SIGHUP])?;        thread::spawn(move || {        for sig in signals.forever() {            match sig {                SIGTERM | SIGINT => {                    println!("終了シグナルを受信");                    std::process::exit(0);                }                SIGHUP => {                    println!("設定再読み込み");                }                _ => unreachable!(),            }        }    });        // メイン処理    loop {        println!("作業中...");        thread::sleep(Duration::from_secs(2));    }}docs.rsgithub.com3. プロセス間通信の基礎シンプルなパイプ通信親プロセスから子プロセスへメッセージを送る基本的な例です。use std::io::{Write, Read};use std::process::{Command, Stdio};fn main() -> std::io::Result<()> {    // catコマンドは標準入力をそのまま標準出力に出力    let mut child = Command::new("cat")        .stdin(Stdio::piped())        .stdout(Stdio::piped())        .spawn()?;        // 子プロセスに書き込み    if let Some(mut stdin) = child.stdin.take() {        stdin.write_all(b"Hello from Rust!\n")?;    }        // 結果を読み取り    let output = child.wait_with_output()?;    println!("受信: {}", String::from_utf8_lossy(&output.stdout));        Ok(())}パイプには特徴的な性質があります。まず単方向通信であり、データは一方向にのみ流れます。またバッファリング機能があり、OSが自動的にバッファを管理してくれます。そしてブロッキング動作をするため、読み込み側は書き込みを待つことになります。docs.rsUnix Domain Socketより本格的な双方向通信の例です。多くのシステムソフトウェアが採用している方式です。Unix Domain Socketには多くの利点があります。双方向通信が可能で、クライアント・サーバー間で自由にやり取りできます。また、ネットワークスタックを通らないため高速に動作します。そしてファイルシステム上のパスとして存在するため、アクセス制御が簡単に行えます。4. デバッグツールの活用詳解 システム・パフォーマンス 第2版作者:Brendan Greggオーム社Amazonシステムプログラミングにおいて、問題を解決するには、まず問題を観察できなければならないという原則があります。特にシグナル処理やIPCのような非同期的な動作は、従来のprint文デバッグでは限界があります。そこで重要になるのが可観測性（Observability）という概念です。効果的なデバッグには階層的なアプローチが必要です。まずアプリケーション層で何が起きているかを把握し、次にシステムコール層まで掘り下げ、必要に応じてカーネル層まで観察します。各層に適したツールを使い分けることで、最小のオーバーヘッドで最大の洞察を得ることができます。また、動的トレーシングと静的トレーシングを使い分けることも重要です。straceのような動的トレーシングツールは実行中のプロセスをリアルタイムで観察でき、rr-debuggerのような記録再生型ツールは時間を巻き戻して問題の根本原因を特定できます。これらを組み合わせることで、再現困難なバグも確実に捕捉できるようになります。strace - システムコールトレースシグナル処理やIPCのデバッグには、システムコールレベルでの動作確認が不可欠です。# シグナル関連のシステムコールのみ表示strace -e trace=signal,sigaction,kill,pause cargo run# 実際の出力例rt_sigaction(SIGINT, {sa_handler=0x5555555, ...}, NULL, 8) = 0--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---rt_sigreturn({mask=[]}) = 0straceを使うと様々な情報が見えてきます。シグナルハンドラーの登録状況（sigaction）、シグナルの送受信タイミング、ブロックされたシグナル、そしてシステムコールの引数と戻り値などを確認できます。strace.iorr-debugger（最強のデバッグツール）rrは、GDBを拡張して作られたデバッガで、プログラムの実行を記録し、逆方向にステップ実行できます。# プログラムの実行を記録rr record ./target/debug/my_program# rust-gdbを使って再生rr replay -d rust-gdb# リバース実行のコマンド(rr) reverse-continue  # 逆方向にcontinue(rr) reverse-next      # 逆方向にnextrrが強力な理由はいくつかあります。まず100%再現性があり、非決定的な動作も完全に再現できます。また逆実行機能により、エラーの原因を遡って調査できます。そして低オーバーヘッドで動作するため、実用的な速度で記録が可能です。特にシステムプログラミングでは、「たまにしか起きないエラー」や「データ競合」のデバッグで威力を発揮します。rr-project.orgtokio-console - 非同期ランタイムデバッグ非同期Rustアプリケーションのデバッグには、tokio-consoleが非常に有用です。タスクの状態、実行時間、リソース使用状況をリアルタイムで監視できます。# tokio-consoleをインストールcargo install --locked tokio-console# アプリケーション起動（別ターミナル）RUSTFLAGS="--cfg tokio_unstable" cargo run# tokio-consoleで監視tokio-consolegithub.com5. グレイスフルシャットダウン実際のサービスで必要な、適切な終了処理の実装例を見てみましょう。グレイスフルシャットダウンが重要な理由は複数あります。まずデータの整合性を保つため、処理中のタスクを完了してから終了する必要があります。またリソースの解放として、ファイルやソケットを適切にクローズしなければなりません。そして状態の保存により、次回起動時に必要な情報を保存することも重要です。実装する際のポイントとしては、まず新規タスクの受付を停止し、新しい仕事を受け付けないようにします。次に既存タスクの完了を待機し、実行中の処理を最後まで実行させます。その後リソースのクリーンアップを行い、ファイルやネットワーク接続を閉じます。最後に統計情報の出力を行い、ログに実行結果を記録します。6. Tokioを使った非同期グレイスフルシャットダウンモダンなRustアプリケーションでは、Tokioを使った非同期処理が主流です。use tokio::signal;use tokio_util::sync::CancellationToken;#[tokio::main]async fn main() {    let token = CancellationToken::new();        // Ctrl+Cハンドラー    let shutdown_token = token.clone();    tokio::spawn(async move {        signal::ctrl_c().await.unwrap();        println!("シャットダウン開始");        shutdown_token.cancel();    });        // メインループ    loop {        tokio::select! {            _ = token.cancelled() => {                println!("終了処理中...");                break;            }            _ = do_work() => {                // 通常の処理            }        }    }}async fn do_work() {    // 非同期処理}CancellationTokenには多くの利点があります。階層的なキャンセルが可能で、親トークンをキャンセルすると子もキャンセルされます。また協調的な仕組みにより、各タスクが自分のタイミングで終了できます。そして非同期対応により、async/awaitと自然に統合されています。tokio.rsdocs.rsgithub.comdocs.rstokio.rs7. nixクレートでシステムコールを扱うRustでは、nixクレートを使って安全にUnixシステムコールを扱うことができます。libcクレートの生のAPIをラップし、Rust的な安全なインターフェースを提供しています。use nix::sys::signal::{self, Signal};use nix::unistd::{fork, ForkResult};match fork() {    Ok(ForkResult::Parent { child }) => {        println!("親プロセス、子PID: {}", child);    }    Ok(ForkResult::Child) => {        println!("子プロセス");    }    Err(_) => eprintln!("fork失敗"),}nixクレートを使うことで、エラーハンドリングが適切に行われ、メモリ安全性が保証されます。生のシステムコールを直接扱う必要がなくなり、より安全なコードが書けるようになります。docs.rsgithub.com8. 2025年の新機能：Async ClosuresRust 1.85.0で安定化されたasync closuresを使うと、より柔軟な非同期処理が書けます。async fn retry_with_backoff<F, Fut>(    mut f: F,     max_retries: u32,) -> Result<String>where    F: FnMut() -> Fut,    Fut: Future<Output = Result<String>>,{    for attempt in 1..=max_retries {        match f().await {            Ok(result) => return Ok(result),            Err(e) if attempt < max_retries => {                let backoff = Duration::from_secs(2_u64.pow(attempt - 1));                sleep(backoff).await;            }            Err(e) => return Err(e),        }    }    unreachable!()}async closuresを使うメリットは多岐にわたります。まず簡潔な記述が可能になり、非同期処理を関数引数として渡せるようになります。また型安全であるため、コンパイル時に型チェックが行われます。そして柔軟な制御フローにより、リトライやタイムアウトの実装が簡単になります。実装パターンの選び方シグナル処理の選択基準シグナル処理の実装方法を選ぶ際は、用途に応じて適切なツールを選択することが重要です。単純な終了処理であればctrlcクレートで十分です。複数のシグナルを扱う必要がある場合はsignal-hookを使用します。そして非同期処理と組み合わせる場合は、Tokioのsignalモジュールが最適です。IPC方式の選択基準IPC方式も同様に、用途に応じて選択します。親子プロセス間の単純な通信であればパイプが適しています。高速な双方向通信が必要な場合はUnix Domain Socketを選びます。大量データの共有には共有メモリが最適で、非同期メッセージングにはメッセージキューが向いています。まとめこの記事では、Rustでのシグナル処理とプロセス間通信について、基礎から実践まで段階的に解説しました。重要なポイント今回学んだ重要なポイントを振り返ってみましょう。まず、シグナルは非同期であり、いつ届くか分からないためアトミック操作が必要です。IPCは用途に応じて選ぶ必要があり、速度、双方向性、複雑さのトレードオフを考慮します。グレイスフルシャットダウンはデータの整合性を保つために必須です。straceやrr-debuggerなどのデバッグツールを活用することで、問題を効率的に解決できます。そして、async closuresやCancellationTokenなどの最新機能を活用することで、保守性を向上させることができます。各IPC方式の使い分け実際の開発では、各IPC方式を適切に使い分けることが重要です。パイプはシェルスクリプトとの連携や親子プロセス間の単純な通信に適しています。名前付きパイプはログ収集や順序保証が必要な場合に使います。Unix Domain Socketは高速な双方向通信やサービス間連携に最適です。共有メモリは大量データの高速処理やリアルタイム性が必要な場合に選択します。次のステップこの基礎を踏まえて、さらに高度な実装に挑戦することができます。分散システムへの拡張としてgRPCやメッセージキューの実装、コンテナ環境でのIPC最適化、リアルタイムシステムでの応用、そしてマイクロサービスアーキテクチャでの実装などが考えられます。完全なソースコードはGitHubリポジトリで公開しています。前回の記事「RustでLinuxプロセス管理をしてみた」と合わせて読むことで、Rustでのシステムプログラミングの基礎がしっかりと身につきます。Linuxカーネルプログラミング 第2版作者:Kaiwan N. Billimoria,武内 覚（翻訳）,大岩 尚宏（翻訳）オライリージャパンAmazon

 RustでLinuxのシグナル処理とプロセス間通信をしてみた

RustでLinuxプロセス管理をしてみた

缶つぶし機とソフトウェア移行技術 - Refactoring to Rust の読書感想文

エンジニアのための「中身のある話」の作り方

さよなら、私の愛したtimesはじめに組織が成長する過程で、かつて機能していた構造が限界を迎える瞬間がある。私はおそらく今、その転換点に立っている。長年愛用してきた社内での個人的な発信空間であるtimesチャンネル(組織によっては分報という名前かも)を閉じることにした。これは単なるチャンネルの使用終了ではなく、組織の成長段階における必然的な選択だと考えている。ちなみにあくまで私の考えで私のみが実行しています。また、いつか復活する可能性もあります。会社の規模が大きくなってきたことを踏まえ、あくまで個人の考えでTimesチャンネルを削除することに決めました。 pic.twitter.com/eZfl1kuf2Q— nwiizo (@nwiizo) 2025年8月3日   このブログが良ければ読者になったり、nwiizoのXやGithubをフォロワーしてくれると嬉しいです。では、早速はじめていきます。timesの光と影小規模組織において、timesや分報などのいわゆるインフォーマルなコミュニケーションチャンネルは組織の血流として機能する。心理的障壁を下げ、階層を超えた知識共有を可能にし、暗黙知を形式知へと変換する触媒となる。しかし、この美しいエコシステムは、ある臨界点を超えると自己矛盾を抱え始める。スケーラビリティの逆説組織が拡大するにつれ、情報の流通経路は指数関数的に増加する。全体性の把握は不可能となり、部分最適化が進行する。かつて全員が共有していた文脈は断片化し、同じ組織にいながら異なる現実を生きることになる。情報の民主化を目指したはずのシステムが、逆に情報格差を生み出す。見える人と見えない人、聞こえる声と聞こえない声。組織の成長とともに、この非対称性は拡大していく。社内には案件のチャンネル、チームのチャンネル、技術のチャンネルが十分に整理されている。今後の発信はこれらの適切なチャンネルで行うことで、より効果的な情報共有を目指す。注意経済と生産性のパラドックス常時接続の環境は、注意力という有限の資源を巡る競争を生み出す。コミュニケーションの活性化が目的だったはずが、いつしかコミュニケーション自体が目的化する。リアクションの数が暗黙の評価軸となり、本来の価値創造から離れていく。組織内SNS化とでも呼ぶべきこの現象は、生産性向上のためのツールが生産性を阻害するという皮肉な結果を生む。心理的安全性の両義性カジュアルさは諸刃の剣である。フラットな対話を促進する一方で、境界線の曖昧さは時に傷を生む。デジタル空間に刻まれた言葉は、文脈を失いながら永続する。過去の自分が未来の自分を、あるいは他者を傷つける可能性を常に孕んでいる。組織構造をちゃんとやる最近読んだ『トリニティ組織』（矢野和男著）は、私の決断に理論的な確信を与えてくれた。組織の生産性と幸福度を決定づけるのは、人間関係の「形」だという。自分の知り合い2人同士も知り合いである「三角形の関係」が多い組織ほど、問題解決能力が高く、孤立も生まれにくい。トリニティ組織:人が幸せになり、生産性が上がる「三角形の法則」作者:矢野 和男草思社Amazontimesの構造について考えると、その限界が明確になる。発信者を頂点に、参加者が個別につながる形 ― これはまさに「V字型の関係」の量産装置である。私のチャンネルを見ているAさんとBさんが、そこでのやり取りを通じて直接つながることは稀だ。むしろ、それぞれが私との1対1の関係に終始する。リモートワーク環境下では、この構造的欠陥はより顕著になる。物理的な偶発的出会いが失われた今、意図的に「三角形」を作り出す仕組みが必要だ。しかし、個人チャンネルという形式は、その本質において中心化を促進し、分散化を阻害する。一方、チームチャンネルや技術雑談チャンネルでは、参加者同士が自然に相互作用する。同じ疑問に対して複数人が異なる視点でアドバイスし、そこから新たな議論が派生する。これこそが知識の三位一体化であり、創造性を高める組織の在り方だ。論理的思考の階層性がV字関係を生み出すという洞察も重要だ。分解と整理を基本とする思考フレームワークは、産業時代には機能したが、知識創造の時代には限界がある。生成AIによる知識の民主化が進む今、組織は階層的構造から、より有機的なネットワーク構造へと進化すべき時を迎えている。私の選択は、V字から三角形へのシフトである。個人の承認欲求を満たす場から、集合知が生まれる場へ。ネットワークのハブとしての自己から、ネットワークの一部としての自己へ。これは単なるツールの変更ではなく、組織内での存在様式の根本的な転換を意味している。時間という有限資源の配分問題個人チャンネルは「アテンション・エコノミー（注意の経済）」における構造的矛盾を抱えている。組織の成長に伴い、情報チャンネルは線形に増加するが、個人の処理能力は一定のまま。この非対称性は、必然的に選別と排除のメカニズムを生み出す。より深刻なのは、この選別が生む不可視の階層構造だ。物理的空間における排除は可視的だが、デジタル空間における排除は不可視でありながら、より根深い分断を生む。参加の自由が保証されているがゆえに、不参加や選択的参加が生む格差は個人の責任に帰されやすい。アテンション・エコノミーのジレンマ　〈関心〉を奪い合う世界に未来はあるか作者:山本 龍彦KADOKAWAAmazon心理的安全性のパラドックス個人チャンネルは心理的安全性を高めるために導入されながら、逆にそれを脅かす装置にもなりうる。これは、親密性と公開性の両立不可能性に起因する。親密な空間であるがゆえに生まれる無防備な発言は、公開空間であるがゆえに永続し、検索可能となる。私自身も経験したことだが、他者への批判を目撃することの疲弊は想像以上に大きい。社内SNS化した空間では、建設的批判と破壊的批判の境界が曖昧になりやすい。「事実と解釈を分ける」という個人的努力に依存する構造は、そもそも持続可能ではない。古参メンバーとしての責任組織の初期メンバーは、文化の形成者であると同時に、その変革の阻害要因にもなりうる。そこまで古参ではないが組織が急拡大しているので相対的に古参である。私の存在が、新しいメンバーにとっての見えない圧力になっていないか。私の発言が、本来生まれるべき多様な声を抑圧していないか。ここで重要なのは、timesの価値は世代や在籍期間によって大きく異なるという認識だ。若手や入社直後のメンバーにとって、timesは今でも有効なツールとして機能している。組織への順応過程において、インフォーマルな発信空間は心理的安全性を提供し、自己開示を通じた関係構築を促進する。新しいメンバーが組織文化を理解し、自分の居場所を見つけるための重要な装置として、その価値は否定できない。また、社長や事業部長といった経営層にとっても、timesは別の意味で価値を持つ。階層的な距離が生む心理的障壁を低減し、人間的な側面を共有することで組織全体の心理的安全性を高める効果がある。経営層の思考プロセスや日常的な悩みが可視化されることで、「雲の上の存在」から「同じ人間」へと認識が変わる。これは特に急成長する組織において、上下の分断を防ぐ重要な機能となりうる。しかし、長く在籍する中間層の一般社員である私の場合、その影響力は異なる性質を持つ。経営層のような明確な役割や責任に基づく発信ではなく、「古参であること」自体が生む見えない権威性が問題となる。この非対称性を自覚したとき、退場もまた一つの貢献となる。若手が自由に発信し、経営層との健全な対話が生まれる空間を守るためにも、中間層の古参は適切なタイミングで身を引く必要がある。個人の節度や自制に依存するシステムは、本質的に脆弱だ。構造的に承認欲求を刺激し、注意力を奪い、関係性を歪めるメカニズムの中で、個人の倫理にどこまで期待できるだろうか。むしろ、そうした個人的努力を不要とする構造へと移行することこそが、組織の進化ではないか。私のチャンネルには、長年の蓄積がある。試行錯誤の痕跡、成功と失敗の記録、人間関係の履歴。これらは個人にとっての財産であると同時に、組織にとっての負債にもなりうる。過去の堆積が未来の可能性を制約するとき、断捨離は創造的行為となる。生成AI時代における組織内コミュニケーション知識のオープン化は、組織の存在理由そのものを問い直している。もはや情報の独占や階層的な知識伝達では、価値創造は不可能だ。必要なのは、多様な視点が交差し、予期せぬ組み合わせが生まれる「場」の設計だ。個人チャンネルは、表面的には情報の民主化に貢献しているように見える。しかし実際には、情報の断片化と選択的可視性による新たな非対称性を生み出している。全体性の把握が不可能な状況下では、部分最適化が進行し、組織は分断される。これからの組織に必要なのは、個人の発信力ではなく、集団としての知識創造力だ。それは、中心化されたネットワークではなく、分散化されたメッシュとして知識が循環する仕組みから生まれる。個から全体へ、閉鎖から開放へ、所有から共有へ。この転換こそが、知識社会における組織の生存戦略となる。卒業という選択すべてのシステムには寿命がある。それを認めることは敗北ではなく、成熟の証である。私にとってのtimesは、その役割を終えた。これは組織の成長を祝福し、新しい段階への移行を受け入れる儀式でもある。個人チャンネルには組織の成長と反比例する有効性がある。規模の拡大は必然的にシステムの限界をもたらす。これは、あらゆる中心化されたネットワークが直面する普遍的な課題だ。組織の成長を喜びながら、その成長に適応できないシステムに固執することは、成長そのものを阻害する。興味深いのは、この空間から離脱した時に感じる「喪失感の不在」だ。むしろ、制約がもたらす創造性の向上を実感している。これは、無限の選択肢よりも適切な制約が人間の創造性を高めるという、古典的な原理の現れかもしれない。「代替可能性」という認識は重要だ。心理的安全性も、知識共有も、偶発的な創発も、すべて異なる構造で実現可能だ。むしろ、より持続可能で公平な形で。個人的な発信空間から、より構造化されたコミュニケーションチャンネルへ。この移行は、組織が次のフェーズに進むための必要な進化だと信じている。終わりに変化を恐れず、執着を手放し、新しい形を模索する。それが成長する組織の中で生きるということだ。私のこの選択は、単なる個人的な決断ではない。V字型の関係から三角形の関係へ、情報の独占から知識の循環へ、個人の承認欲求から集合知の創発へ。これは、知識社会が求める組織変革の、小さな、しかし確かな一歩だ。真の課題は特定のツールの有無ではなく、組織における関係性の質にある。健全な組織文化は、ツールを超えて、人と人との相互作用の中から生まれる。私のこの選択が、組織のコミュニケーション構造について考える一つのきっかけになれば幸いである。これまでの対話に感謝を込めて。そして、新しい形での再会を楽しみにしている。参考Slackのtimesのメリット・デメリットについて改めて考えてみる｜斎藤 雅史Slackの分報チャンネル使うのやめた - stefafafan の fa は3つですSlackの分報チャンネル使うのを再開していた - stefafafan の fa は3つですまたSlackでtimesを始めてしまった｜ばんくし分報を導入して3年経ったので振り返る - FRTKL

組織の成長に伴う私のtimes の終焉についての思索

2025年夏 AIエージェントシステムに対する考え方

「 転職したらMCPサーバーだった件」というタイトルで登壇したことがある。本日は「JAWS-UG SRE支部 #13 つよつよSREの秘伝のタレ」というなんとなく強そうなイベントで登壇しました。🔍 イベント詳細:- イベント名: JAWS-UG SRE支部 #13 つよつよSREの秘伝のタレ- 公式URL: https://jawsug-sre.connpass.com/event/358781/- ハッシュタグ: https://x.com/search?q=%23jawsug_sre&f=live- 参考資料①: https://speakerdeck.com/nwiizo/zhuan-zhi-sitaramcpsabadatutajian

転職したらAWS MCPサーバーだった件

しんどくなったので説明した。良くなるかもしれないし悪化するかもしれません。はじめに私たちは常に「強くあること」を求められている。生成AIよりも成果を出すことを求められている。NEXUS 情報の人類史 下　AI革命作者:ユヴァル・ノア・ハラリ河出書房新社Amazonかつては人間同士の競争だった。同僚より早く仕事を終わらせ、他社より良い製品を作り、去年の自分を超えることが目標だった。しかし今、比較対象は常時稼働し、瞬時に大量のアウトプットを生成し、日々賢くなっていくAIになった。「毎年成長し続ける」「常に結果を出す」「社会の変化に乗り遅れない」という従来のプレッシャーに加え、「AIより価値のある仕事をする」という不可能に近い要求が加わった。ブルシット・ジョブ　クソどうでもいい仕事の理論作者:デヴィッド グレーバー岩波書店Amazon朝、デスクに向かう。スマホには新しいAIツールのリリースニュースが並ぶ。コーヒーを飲みながら思う。「来年のAIなら、この仕事を何分で終わらせるんだろう」と。この問いに答えはない(そして意味もあまりない)。確実に言えることは来年のAIは、今年のAIより確実に賢くなっているのだから。この新たな競争の中で、多くの人が説明のつかない「しんどさ」を抱えている。「ちゃんとした社会人or エンジニア」として頑張っているはずなのに、自分が自分でなくなっていくような感覚にとらわれている。AIが瞬時に生成できるコードを何日もかけて書いている自分。AIが即座に答えを出す問題で悩んでいる自分。そんな自分に価値があるのかという問いが、心の奥底で響き続ける。このブログが良ければ読者になったり、nwiizoのXやGithubをフォロワーしてくれると嬉しいです。では、早速はじめていきます。AI疲れという新たな現象現代社会が個人に課す「強さ」への過剰な期待は、組織で働く人々に深い疲労感をもたらしている。成長至上主義、時間の効率化への強迫観念、能力主義の弊害――これらが複雑に絡み合い、私たちの働き方と生き方を息苦しいものにしている。疲労社会作者:ビョンチョル・ハン,横山陸花伝社Amazonさらに最近では、「AI疲れ（AI fatigue）」という新たな疲労が職場に蔓延している。@t_wadaさんがとても良い分類を出しているのでここに従う。AI疲れとは、AIの絶え間ない進歩のペースに対応しようとすることで生じる、精神的・感情的・業務的な消耗状態を指す。この現象は単一の原因ではなく、複数の要因が絡み合って生じている。最近の「AI疲れ（AI fatigue）」は2種類ありそう。1つめはわかりやすく「AIの進化が速すぎるのでキャッチアップに疲れる」なのだけど、2つめは「AIの仕事が速すぎるので人間がボトルネックになり、休みなく高頻度で判断が迫られ続け、労働強度が高すぎて疲れる」だと考えている。— Takuto Wada (@t_wada) 2025年5月29日   まず、技術的な複雑さと継続的な変化がもたらす疲労がある。GitHub Copilotのような補完型から、ChatGPTのような対話型、そして自律的にタスクを遂行するClaude Codeのようなコーディングエージェントへ――この急速な進化は、学習と適応の終わりなきサイクルを生み出している。研究者は新しい論文を統合するために絶えず自分の研究を更新し、エンジニアチームは新モデルがリリースされるたびにシステム全体を更新する無限のスプリントに追われる。次に、AIの処理速度と人間の処理能力のミスマッチによる疲労がある。AIが瞬時に大量のアウトプットを生成する一方で、人間はそのすべてをレビューし、判断し、統合しなければならない。これは「人間がボトルネックになる」という新たな現象を生み出し、休みなく高頻度で判断が迫られ続ける状況を作り出している。決定疲労（Decision Fatigue）も深刻な問題だ。AIが提供する無数の選択肢や提案から、人間が最終的な判断を下し続けなければならない。これは従来の「作業疲労」とは質的に異なる、認知的な消耗をもたらす。朝から晩まで「このAIの提案は正しいか」「どの選択肢を選ぶべきか」という高度な判断を迫られ続ける。誰かが言った。「AIのおかげで単純作業から解放されたと思ったら、今度は判断作業の奴隷になった」と。さらに、期待と現実のギャップが組織全体に失望と疲労を蓄積させている。「AIが全てを解決する」という過大な約束と、実際の導入で直面する困難との間に大きな溝がある。プルーフ・オブ・コンセプトの失敗、期待された成果の不達成、投資に見合わないリターン――これらが「AI疲れ」を増幅させる。情報過負荷も無視できない。AIに関する情報――新しいツール、ベストプラクティス、倫理的考慮事項、セキュリティ上の懸念――が洪水のように押し寄せ、何が本当に重要なのか判断することすら困難になっている。そしてプラスして根底には、職務置換への恐怖がある。多くの労働者、特に若年層が、AIによって自分の仕事が陳腐化することを心配している。この恐怖は、AIを使わなければ「遅れている」と見なされ、使えば自分の仕事がなくなるかもしれないという、逃げ場のないジレンマを生み出している。AIが映し出す人間の「弱さ」の本質このAI疲れは、既存の成長至上主義と結びついて、より複雑な疲労を生み出している。歴史が示すように、新技術は常に労働者への期待値を上げてきた。かつてのキッチン家電は家事を楽にしたが、同時により複雑な料理への期待も生んだ。スマートフォンは常時接続可能な状態を生み出した。そして今、AIは「無限の生産性」という新たな基準を作り出している。AIツールを使いこなせなければ「遅れている」と見なされ、使いこなしても今度は人間がAIのペースに合わせて働かなければならない。技術が人間を助けるのではなく、人間が技術に仕える逆転現象が起きている。ChatGPTが驚異的な速さで普及したように、AIの浸透速度は過去のどの技術よりも速く、適応の猶予すら与えられない。リーダー層の疲労はさらに深刻だ。多くのシニアリーダーがAIの急速な成長の中で「失敗している」と感じており、組織全体のAI導入への熱意が低下していると報告されている。彼らは「ダブルバーデン」を背負う――AIを採用して効率化を図りながら、同時に組織文化の変革も管理しなければならない。精神的疲労、決定疲労、そして個人的満足度の低下が、経営層レベルで蔓延している。さらに深刻なのは、社会が求めるものがタスクの遂行だけになった時、人間は無限に働けるAIと直接比較されるという新たな構造だ。生成AIやAIエージェントは常時稼働し、休憩も睡眠も必要とせず、感情的にもならず、体調不良で休むこともない。複数のタスクを並行処理し、瞬時に大量のコードを生成する。この「無限の生産性」を持つ存在と比較された時、人間の当たり前の特性――疲れる、眠る、休憩が必要、感情がある、体調を崩す――これらすべてが「弱さ」として強調されてしまう。強いビジネスパーソンを目指して鬱になった僕の 弱さ考作者:井上 慎平ダイヤモンド社Amazon従来の「弱さ」とは、社会が求める「常に成長し、生産的である人間像」になれないことだった。しかしAI時代においては、その基準自体が人間には到達不可能なものになった。常時働けるAI、感情に左右されないAI、無限に学習し続けるAI――これらと比較される時、人間の生物学的限界そのものが「弱さ」として定義されてしまう。日々賢くなるAIと、日々衰える人間最も残酷な現実は、日に日に賢くなるAIと、日に日にAIに依存して能力が落ち、当たり前に老いていく自分との対比だ。AIは毎日アップデートされ、より高速に、より正確に、より創造的になっていく。一方で人間は、AIに頼るほど自分で考える機会を失い、コードを書く能力は錆びつき、そして確実に年を重ねていく。この構造的な非対称性の前で、「辛くない」という感情を持つ方が難しい。かつて電卓の登場で暗算能力が衰えたように、AIへの依存は確実に私たちの能力を変化させる。しかし、暗算と違って、プログラミングや問題解決能力は知的労働者のアイデンティティの核心だ。それが日々失われていく感覚は、単なるスキルの喪失以上の、存在論的な不安をもたらす。新たな職務形態の苦悩特に深刻なのは、AIの導入によって仕事の性質が根本的に変わることだ。「AIマインスイーパー」と呼ばれる現象――簡単なタスクはすべてAIが処理し、複雑で責任の重いタスクだけが人間に残される。まるで地雷原を歩くように、人間は常に高リスクの判断を迫られ続ける。多くのソフトウェアエンジニアがバーンアウトを経験しているという現実が、この状況の過酷さを物語る。gigazine.netまた、プレイヤーからマネージャーへの急激な役割変化も新たな適応課題を生んでいる。かつては自分でコードを書いていた開発者が、今や複数のAIエージェントを管理し、それらの成果物を統合する「AIマネージャー」となる。しかし、誰もがマネジメントに向いているわけではない。コードを書く喜びを奪われ、望まない管理業務に追われる日々は、多くの開発者にとって職業的アイデンティティの喪失を意味する。特に痛切なのは、AIと生産性を比較される瞬間だ。「AIならすぐにできることに、なぜ君はそんなに時間がかかるのか」「AIは休まないのに、なぜ君は疲れたと言うのか」――こうした比較は、人間としての基本的なニーズを「非効率」として否定する。働いて疲れることが「弱さ」になり、週末に休むことが「生産性の低さ」になる。人間であることそのものが、欠陥のように扱われる瞬間だ。syu-m-5151.hatenablog.com組織に広がる失望と疲労AI時代の適応課題は、より複雑で多層的だ。期待と現実のギャップが組織全体に疲労をもたらす。「AIが全てを解決する」という楽観的な約束と、実際の導入で直面する困難との間に大きな溝がある。企業の半数以上が、全社的なAI導入への熱意が低下していると報告している。プルーフ・オブ・コンセプトの失敗、期待された成果の不達成、そして投資に見合わないリターン――これらが組織に失望と疲労を蓄積させる。さらに、倫理的な懸念による疲労も無視できない。プライバシー、監視、バイアスといったAIの倫理的問題について、現場の従業員は無力感を抱えながら日々AIを使用している。「これは正しいことなのか」という問いを抱えながら、それでも使わざるを得ない状況は、深い心理的ストレスを生む。「変化を嫌う人」を動かす:魅力的な提案が受け入れられない4つの理由作者:ロレン・ノードグレン,デイヴィッド・ションタル,船木 謙一(監修)草思社Amazonまとめ私たちは今、人類史上初めて、知的労働において機械と比較される時代を生きている。生成AIよりも成果を出すことを求められ、無限に働き続けるAIと生産性を比較され、日々賢くなるAIを横目に自分の能力の衰えを感じている。この構造的な非対称性――AIは日々進化し、人間は日々老いる――の前で、「辛くない」という感情を持つ方が難しい。AIに依存すればするほど自分の能力は錆びつき、それでもAIなしでは競争できない。このジレンマに、多くの人が説明のつかない「しんどさ」を抱えている。日に日に賢くなるAIを見ながら、自分の能力の衰えを感じる辛さ――この経験こそが、実は最も普遍的で、最も共有可能な凡人の体験になりつつある。若手開発者も、ベテランも、新卒のエンジニアも、みな同じ不安を抱えている。「昨日できたことが、今日はAIの方が上手くやる」「来年の自分は、今年の自分より相対的に無能になっている」――この残酷な現実を前に、辛くないと感じられる人などいるだろうか。居るなら俺を救ってくれ…。

AI時代の新たな疲労：なぜ私(たち)は『説明のつかないしんどさ』を抱えているのか

Claude CodeのHooksは設定したほうがいい

開発生産性を測る時に測定の落とし穴から抜け出すために

正義のエンジニアという幻想 - 媚びないことと無礼の境界線

生成AIで物語を書くためにプロンプトの制約や原則について学ぶ、という話をしてきました #女オタ生成AI部

諸君、聞かれよ。本日、私は「女オタ生成AIハッカソン2025夏東京」なる前代未聞の催しにて、生まれて初めて登壇することと相成った。かつての私は純朴なプログラマーであり、「変数名を30分悩んだ挙句、結局tmpにする」という、実に平凡な悩みを抱える程度の技術者であったのだ。歳月は容赦なく流れ、今や私はプロンプトエンジニアリングという名の魔境に足を踏み入れた哀れな求道者となり果てた。昨夜も丑三つ時まで、私は薄暗い書斎でディスプレイの冷たき光に照らされながら、「なぜ生成AIは『簡潔に』と百回唱えても、源氏物語の長文を生成するのか」という哲学的難題と格闘していたのである。30分という持ち時間に対し50枚のスライドを用意するという、まるで賽の河原で石を積む如き徒労に及んでいる。そのうち半分は「プロンプトという名の現代呪術における失敗例集」と題した、私の苦悩の結晶である。ああ、AIとの対話とは、かくも人間の正気を奪うものなのか。---ブログも書いた。生成AIで物語を書くためにプロンプトの制約や原則について学ぶ、という話をしてきました #女オタ生成AI部https://syu-m-5151.hatenablog.com/entry/2025/06/30/171149

生成AIで小説を書くためにプロンプトの制約や原則について学ぶ / prompt-engineering-for-ai-fiction 

〜日報をサボってしまう人のための解決策〜日報、めんどくさいよね正直に言います。日報書くの、めんどくさいですよね。僕も毎日終業時に「あれ、今日何やったっけ...」ってなって、GitHubでクローズしたIssue探したり、Slackでミーティングの議事録掘り返したり、Jiraのチケット確認したり...。正確に書こうとすると、気づいたら15分とか経ってるんですよね。しかも、やっと書き終わったと思ったら「あ、そういえば午前中にあのバグ直したの書き忘れた」「レビューで指摘もらった内容も書かなきゃ」みたいなことがしょっちゅう。正直、この作業が苦痛すぎて、サボっちゃう日もありました。「明日まとめて書けばいいや」って思って、結局3日分まとめて書く羽目になったり...（そして当然、細かいことは忘れてる）。でも最近、Claude Codeのカスタムslash commandsを使い始めてから、この苦行から解放されたんです。作業しながらサクッと記録できるようになって、もう日報をサボることがなくなりました。今回は、僕が実際に使ってる日報システムを紹介します。このブログが良ければ読者になったり、nwiizoのXやGithubをフォロワーしてくれると嬉しいです。では、早速はじめていきます。Claude Codeのslash commandsって何？Claude Codeには、よく使うプロンプトをコマンド化できる機能があるんです。簡単に言うと、Markdownファイルを特定のフォルダに置くだけで、オリジナルコマンドが作れちゃいます。この機能について詳しく知りたい人は、こちらの記事がめちゃくちゃ参考になります()。syu-m-5151.hatenablog.comカスタムコマンドの仕組みから活用法、トラブルシューティングまで網羅的にまとまってて、僕も参考にさせてもらってます。特に、v1.0.25でプレフィックスが不要になったとか、frontmatterでdescription書く方法とか、知らなかったTipsがたくさんありました。で、今回はこの機能を使って日報を楽にする方法を紹介します。# こんな感じで使える/nippo-add バグ直した！僕の日報の悩みと解決策フィードバックと内省は成長に欠かせない要素です。頭では理解していても、いざ日報を書くとなると腰が重くなってしまう。「成長したい」という願望と「面倒くさい」という本音の狭間で揺れ動く——そんな矛盾を私自身も抱えています。 speakerdeck.comBefore：苦痛すぎてサボる悪循環終業時に「さて、日報書くか...」と思っても、GitHubで今日クローズしたIssueを探すSlackでミーティングの議事録を掘り返すJiraでチケットのステータス確認「あれ、午前中何してたっけ...」と記憶を辿るやっと書き始める書いてる途中で「そういえば...」と思い出して追記この作業が苦痛すぎて、つい「今日はいいや...」ってサボっちゃうんですよね。で、翌日になると、昨日の記憶があいまい「えーと、昨日の分も書かなきゃ...」さらに苦痛度アップまた今日もサボる最悪のときは3日分まとめて書く羽目に。当然、細かいことは全部忘れてて、「Issue対応しました」みたいな雑な日報になっちゃう。After：作業中にポチポチ記録Claude Codeで作業してる最中に/nippo-add バグ#123修正完了。nullチェック忘れてた。恥ずかしい...これだけ！後でAIが整形してくれるから、とりあえず記録しとけばOK。何が変わったか、その場で記録するから苦痛じゃないIssue番号もその場で記録するから探さなくていい感情も新鮮なうちに残せる/nippo-finalize で自動整形もうサボらない！（これが一番大きい）（今だけの可能性すらある）でも、日報を書く心理的ハードルがめちゃくちゃ下がりました。実際に作った3つのコマンド僕が使ってるのは、たった3つのコマンドです。実は本当はもっと詳しく作り込んでて、プロジェクト固有の処理とか、社内のテンプレートに合わせた出力とか入れてるんですが、汎用的に使えそうな部分だけ抜き出して紹介します。これでも十分使えるはず！1. /nippo-add - とにかく記録作業中に思いついたことを何でも突っ込みます。.claude/commands/nippo-add.md（またはホームディレクトリの~/.claude/commands/nippo-add.md）に以下の内容を保存：# 日報に追記する現在の日報ファイル（/tmp/nippo.$(date +%Y-%m-%d).md）に以下の内容を追記してください。## 追記する内容: $ARGUMENTSまず、日報ファイルが存在するか確認し、存在しない場合は新規作成してください。### 新規作成の場合のテンプレート:---markdown# 日報 $(date +%Y年%m月%d日)## 📝 作業ログ### $(date +%H:%M) - 初回記録$ARGUMENTS---## 🎯 今日の目標- [ ] （後で記入）## 📊 進捗状況（セッション終了時に記入）## 💡 学びと気づき（随時追記）## 🚀 明日への申し送り（本日終了時に記入）---### 既存ファイルへの追記の場合:1. 「## 📝 作業ログ」セクションを探す2. そのセクションの最後に以下の形式で追記:--markdown### $(date +%H:%M) - $ARGUMENTS の要約（20文字以内）$ARGUMENTS---### 特別な処理:- もし `$ARGUMENTS` に「振り返り:」が含まれる場合は、「## 💡 学びと気づき」セクションに追記- もし `$ARGUMENTS` に「明日:」が含まれる場合は、「## 🚀 明日への申し送り」セクションに追記- もし `$ARGUMENTS` に「目標達成:」が含まれる場合は、「## 🎯 今日の目標」セクションの該当項目にチェックを入れるポイントは、「振り返り:」とか「明日:」ってキーワードをつけると、自動的に適切なセクションに振り分けてくれること。これ、地味に便利。あと、Issue番号とかPR番号も一緒に書いておけば、後で「あれどのIssueだっけ？」ってGitHub探し回らなくて済みます。2. /nippo-finalize - AIに仕上げてもらう終業時に実行すると、散らかった作業ログから、ちゃんとした日報を作ってくれます：# 日報を完成させる本日の日報（/tmp/nippo.$(date +%Y-%m-%d).md）を完成させます。## 実行内容:1. **進捗状況の集計**   - 作業ログから本日の活動を分析   - 達成した項目と未達成の項目を整理2. **各セクションの補完**   - 空欄になっているセクションを埋める   - 作業ログから重要なポイントを抽出[以下省略...]これがすごいのは、書き忘れた「よかったこと」とか「改善点」を、作業ログから勝手に抽出してくれるところ。「あー、そういえばそれも書かなきゃ」みたいなのがなくなりました。3. /nippo-show - 確認用単純に今日の日報を表示。週次サマリーも見れます。実際の1日の流れ朝イチ$ /nippo-add スタンドアップ終了。今日は#456と#457に取り組む。#456から着手午前中のコーディング$ /nippo-add #456 実装開始。思ったより複雑...$ /nippo-add うーん、原因がわからん。デバッガで追ってみる$ /nippo-add やった！原因判明。非同期処理のタイミングの問題だった$ /nippo-add 振り返り: async/awaitの理解が甘かった。MDN読み直そうPRレビュー$ /nippo-add PR #234 レビュー完了。セキュリティ的な懸念点を指摘$ /nippo-add 自分のPR #235 もレビュー依頼出した昼休み後$ /nippo-add 定例MTG: スプリントの進捗確認。予定通り進んでることを報告$ /nippo-add 田中さんに相談したら一瞬で解決策を教えてくれた。さすが...$ /nippo-add #456 修正完了！テストも全部通った！PR作成 → #789夕方$ /nippo-add PR #789 にレビューコメントもらった。明日対応する$ /nippo-add 明日: #789のレビュー対応、#457の実装、ドキュメント更新$ /nippo-finalizeたったこれだけ！その場その場で記録するから、もうGitHubとSlackを行ったり来たりする必要なし。個人用コマンドとして設定する方法さっきのスクショにあるように、~/.claude/commands/に置けば、どのプロジェクトでも使えるようになります。これがめちゃくちゃ便利。# ホームディレクトリに個人用コマンドを作成mkdir -p ~/.claude/commandscd ~/.claude/commands# 3つのファイルを作成touch nippo-add.md nippo-finalize.md nippo-show.mdあとは上記の内容をコピペすれば完了！これの何が良いかって：- 会社のプロジェクトでも個人プロジェクトでも同じコマンド- プロジェクト切り替えても日報は一つ（/tmp/nippo-YYYY-MM-DD.mdに統一）- 複数プロジェクトまたいで作業した日も、一つの日報にまとまる実際、僕は午前中は会社のプロジェクト、午後は個人のOSS開発とかやることもあるんですが、全部一つの日報にまとまるから管理が楽です。使ってみて分かったコツ1. Issue番号やPR番号も一緒に記録後で見返すとき、めちゃくちゃ便利です。/nippo-add #456 修正完了。レビュー待ち/nippo-add PR #789 のレビュー対応完了。CIも通った！2. 恥ずかしがらずに感情も記録# これだと味気ない/nippo-add バグ修正完了# 感情も入れると後で読み返して楽しい/nippo-add バグ修正完了！3時間も悩んだけど解決してスッキリ！3. ミーティングの要点もその場でミーティング終わったら、議事録作る前にサクッと：/nippo-add 定例MTG: 来週のリリース内容確認。自分は認証機能を担当/nippo-add 振り返り: スプリントの振り返りで工数見積もりの甘さを指摘された。次は1.5倍で見積もる4. 失敗も正直に書く完璧な日報より、失敗も含めた正直な日報の方が、後で振り返ったときに学びが多いです。/nippo-add やらかした...本番DBに接続してた。幸い読み取りだけだったけど冷や汗/nippo-add 振り返り: 環境変数の確認を怠った。チェックリスト作ろう5. 細かいことでも記録「これくらい書かなくてもいいか」と思うようなことも、意外と後で役立ちます。/nippo-add VS Codeの新しい拡張機能試した。Error Lensめっちゃ便利/nippo-add TypeScriptのバージョン上げたらビルド時間が20%短縮されたトラブルシューティング「コマンドが認識されない！」僕も最初これでハマりました。原因は大体：- ファイルの拡張子が.mdじゃない（.txtにしちゃってた）- ファイル名にスペース入れちゃってる- Claude Code再起動し忘れ「$ARGUMENTSが展開されない」これも罠。$ARGUMENTSは完全一致じゃないとダメです。$arguments（小文字）とか${ARGUMENTS}（波括弧付き）は動きません。もっと自動化できるけど？究極的にはnippo-addすら自動化できるっちゃできるんですよね⋯。実際、僕も「PR作成したら自動で日報に追記」みたいなの試してみたことあります。でも結局、感情とか気づきは自分で書きたいんですよね。「やった！」とか「これハマった...」みたいな。だから今は、技術的には自動化できる部分も、あえて手動で /nippo-add してます。その方が振り返りの質が高くなる気がして。でも、チームや人によっては完全自動化もアリかも。特に定型的な作業が多いチームとか。このへんは好みと文化次第ですね。まとめ正直、このシステムを使い始めてから、日報を書くのが苦じゃなくなりました。むしろ、1日の成果を振り返るのが楽しみになってる自分がいます。一番の変化は、Before: 日報書くの面倒 → サボる → 翌日もっと面倒 → またサボる（悪循環）After: その場で記録 → 苦痛じゃない → 毎日続く → 習慣になる（好循環）特に良いのは、記憶が新鮮なうちに記録できる（Issue番号も間違えない）感情も含めて残せる（これ重要）AIが整形してくれるから、雑に書いてもOK毎日の成長が見える化される何より、サボらなくなった！(今だけだとしても)もし「日報めんどくさい...」「つい後回しにしちゃう...」「3日分まとめて書いてる...」って人がいたら、ぜひ試してみてください。最初の設定は10分もかからないし、その後の精神的な楽さを考えたら、圧倒的にコスパ良いです。あと、チームで使うとさらに面白いです。みんなの「振り返り」を読むと、「あー、そこで悩んでたのか」とか「その解決方法は思いつかなかった」とか、学びが多いんですよね。日報を「苦痛な義務」から「成長ツール」に変える。Claude Codeのslash commandsなら、それができます。Happy Logging! 🚀P.S. この記事書いてて思ったけど、ブログも/blog-addみたいなコマンド作ったら楽になりそう...今度やってみよう。というか日報をというお題からあなたの問題を解決するヒントを得てください。

Claude CodeのSlash Commandsで日報を作成する

Claude Code の .claude/commands/**.md は設定した方がいい

自己認識から自己拡張へについて.md

はじめにAIコーディングエージェント（Claude Code、Cursor、Cline等）の普及により、開発効率は飛躍的に向上しました。しかし、複数のAIエージェントを同時に使用する際、以下のような課題に直面することがあります：ファイルの競合: 複数のエージェントが同じファイルを同時に編集環境の汚染: 一つのエージェントの変更が他の作業に影響作業追跡の困難: どのエージェントが何を変更したか把握しにくいこれらの課題を解決するのが、Daggerが開発したContainer-Useです。github.comDaggerとは何かDaggerはDockerの創設者Solomon Hykes氏が2018年に立ち上げた会社で、「DevOpsオペレーティングシステム」の構築を目指しています 。コンテナで開発者の問題を解決したHykesは、今度は「CI/CDの混乱状態」という開発者とインフラの間の複雑な問題に挑戦しています 。Container-UseとはContainer-Useは、AIエージェント向けのMCP（Model Context Protocol）サーバーで、各エージェントに独立したコンテナ環境を提供します。dagger.io主要な機能隔離されたコンテナ環境: 各AIエージェントが独立した環境で動作Gitブランチによる変更管理: すべての変更が自動的にGitブランチに記録リアルタイム監視: cu watchコマンドで全環境の動作を一元監視複数環境の並列実行: 複数のエージェントが干渉することなく同時作業可能インストールと初期設定前提条件Docker（macOSの場合はColima推奨）Gitインストール方法# Homebrewを使用brew install dagger/tap/container-use# または、curlを使用curl -fsSL https://raw.githubusercontent.com/dagger/container-use/main/install.sh | bashgithub.comClaude Codeとの連携設定.claude/settings.local.jsonに以下を追加：{  "mcpServers": {    "container-use": {      "command": "container-use"    }  },  "permissions": {    "allow": [      "mcp__container-use__environment_open",      "mcp__container-use__environment_file_write",      "mcp__container-use__environment_run_cmd",      "mcp__container-use__environment_update"    ]  }}実際の動作例1. MCP経由でのContainer-Use操作Claude Code内でContainer-Use MCPサーバーを使用して、実際に環境を作成・操作した例です：# test-cu-demo環境を作成environment_id: test-cu-demo/polite-herring# Pythonスクリプトを作成して実行#!/usr/bin/env python3import osimport socketprint("Hello from Container-Use!")print(f"Hostname: {socket.gethostname()}")print(f"Working Directory: {os.getcwd()}")# 実行結果：# Hello from Container-Use!# Hostname: dagger# Working Directory: /workdir2. リアルタイム監視（cu watch）cu watchコマンドを実行すると、すべての環境の動作をリアルタイムで監視できます。各環境での操作（ファイル作成、コマンド実行等）が時系列で表示されます。3. Webアプリケーションの実行Container-Use内でWebアプリケーションを実行し、ポートを公開することも可能です：# 簡単なHTTPサーバーを作成from http.server import HTTPServer, BaseHTTPRequestHandlerclass SimpleHandler(BaseHTTPRequestHandler):    def do_GET(self):        self.send_response(200)        self.send_header('Content-type', 'text/html')        self.end_headers()        self.wfile.write(f'''        <html>            <body>                <h1>Hello from Container-Use!</h1>                <p>Container Hostname: {socket.gethostname()}</p>            </body>        </html>        '''.encode())# ポート8080で実行 → localhost:61753にマッピング実際に公開されたサイトのスクリーンショットでは、コンテナ内で動作するアプリケーションがブラウザから正常にアクセスできることが確認できます。基本的な使い方Container-Use MCPサーバーの主な機能Container-UseはMCPサーバーとして動作し、AIエージェントから以下の操作が可能です：environment_open: 新しい環境を作成environment_file_write: ファイルの作成・編集environment_file_read: ファイルの読み取りenvironment_run_cmd: コマンドの実行environment_update: 環境の更新（パッケージインストール等）environment_file_delete: ファイルの削除監視コマンド# リアルタイム監視cu watch# 環境一覧cu list# ログ確認cu log <環境名>まとめContainer-Useは、AIコーディングエージェントに安全で隔離された実行環境を提供する革新的なツールです。主な利点：完全な隔離: 各エージェントが独立した環境で動作透明性: すべての操作がGitブランチに記録並列性: 複数のエージェントが干渉なく同時作業安全性: メイン環境を汚染しない実験が可能AIエージェントを活用した開発をより安全で効率的にしたい方は、ぜひContainer-Useを試してみてください。参考リンクContainer-Use GitHubMCP (Model Context Protocol)Dagger公式サイト

「やっちゃえ、バーサーカー」Container-Useで実現するAIエージェントの開発環境

「実装」から「設計」へのパラダイムシフト というより無限に体力が必要という話をした #KAGのLT会

僕がClaude Codeに初めて触れたのは、2025年の春だった。生成AIにはすでに慣れ親しんでいた。流行に乗り遅れてはいけないと必死に勉強し、エディターの補完機能やコード生成ツールとして日常的に活用していた。ただ、当時の僕にとってそれはまだ「CLIで動く便利なコーディング支援ツール」程度の認識でしかなかった。「AIが90%のコードを自動生成」という謳い文句を見ても、半信半疑でターミナルを開いたのを覚えている。イベント名:【オフライン開催】KAGのLT会 #6 〜御社のエンジニア育成どうしてる!? スペシャル〜公式URL: https://kddi-agile.connpass.com/event/357862/「実装」から「設計」へのパラダイムシフト というより無限に体力が必要という話をした https://syu-m-5151.hatenablog.com/entry/2025/06/19/102529【参考文献】  - 公式ドキュメント    - Claude Code 公式サイト https://www.anthropic.com/claude-code    - Claude Code ドキュメント https://docs.anthropic.com/en/docs/claude-code/overview    - Claude Code Best Practices https://www.anthropic.com/engineering/claude-code-best-practices    - 抽象化をするということ - 具体と抽象の往復を身につける https://speakerdeck.com/soudai/abstraction-and-concretization    - How I Use Claude Code https://spiess.dev/blog/how-i-use-claude-code    - LLMの制約を味方にする開発術 https://zenn.dev/hidenorigoto/articles/38b22a2ccbeac6    - Claude Code版Orchestratorで複雑なタスクをステップ実行する https://zenn.dev/mizchi/articles/claude-code-orchestrator    - Agentic Coding Recommendations https://lucumr.pocoo.org/2025/6/12/agentic-coding/    - Claude Codeに保守しやすいコードを書いてもらうための事前準備 https://www.memory-lovers.blog/entry/2025/06/12/074355    - Claude Codeによる技術的特異点を見届けろ https://zenn.dev/mizchi/articles/claude-code-singularity-point

Claude Code どこまでも/ Claude Code Everywhere

自動承認

技術的負債の変質について

Claude Code の CLAUDE.mdは設定した方がいい

IntroductionAs developers, we often juggle multiple contexts throughout our day - switching between personal projects, client work, and perhaps some experimental code on the side. Each context might require different permissions, access levels, and configurations. If you're using Claude Code, Anthropic's CLI tool for interacting with Claude, you've probably felt the pain of manually managing different settings.json configurations. That's why I built cctx - a fast, intuitive context switcher for Claude Code, inspired by the excellent kubectx tool for Kubernetes.github.comThe Problem: Configuration Context SwitchingClaude Code uses a settings.json file to control permissions, access levels, and various configurations. This is great for security and customization, but becomes cumbersome when you need different settings for different scenarios:Work projects need restricted permissions for safetyPersonal projects might need full access to your file systemClient demos require ultra-restricted settings for screen sharingExperimental work needs different tool accessManually editing settings.json or maintaining multiple copies quickly becomes error-prone and tedious. I needed something better.docs.anthropic.comEnter cctx: Fast Context Switching for Claude Codecctx (Claude Context) brings the simplicity and speed of kubectx to Claude Code configuration management. Written in Rust for maximum performance, it allows you to switch between different Claude Code configurations with a single command:# Switch to work context (restricted permissions)cctx work# Switch to personal context (full permissions)cctx personal# Switch back to previous contextcctx -Design Philosophy: Predictable Defaults with Progressive DisclosureOne of the key lessons learned during development was the importance of predictable behavior. In version 0.1.1+, I completely redesigned the UX around a simple principle: predictable defaults with explicit overrides.What This Means in PracticeDefault behavior is always the same - cctx always manages user-level contexts (~/.claude/settings.json) unless explicitly told otherwiseNo surprising auto-detection - The tool won't suddenly switch to project-level contexts just because you're in a different directoryProgressive disclosure - When project or local contexts are available, helpful hints guide you to themExplicit when needed - Use --in-project or --local flags when you want to manage other context levelsThis approach eliminates cognitive overhead while maintaining full functionality for advanced users.Key Features That Make cctx Shine🚀 Lightning FastBuilt with Rust, cctx switches contexts in milliseconds. No Python startup overhead, no Node.js dependencies - just pure speed.🎨 Beautiful, Intuitive InterfaceColor-coded output with the current context highlighted in greenHelpful emoji indicators for different context levels (👤 User, 📁 Project, 💻 Local)Interactive fuzzy search with fzf integration or built-in finderClear, actionable error messages🛡️ Security-First DesignCreate separate contexts for different security requirements:# Create a restricted work contextcctx -n workcctx -e work  # Edit to add restrictions# Create a demo context for screen sharingcctx -n demo  # Ultra-restricted, read-only📁 Simple File-Based StorageContexts are just JSON files stored in ~/.claude/settings/. You can edit them manually, version control them, or sync them across machines.Real-World Usage PatternsHere's how I use cctx in my daily workflow:Morning Routine# Start the day with work contextcctx work# Check what context I'm incctx -c# Output: workProject Switching# Working on a personal projectcctx personal# Client calls - need to share screencctx demo# Back to personal projectcctx -Context Management# Create a new context for a specific clientcctx -n client-acme# Edit the context to set appropriate permissionscctx -e client-acme# List all contextscctx# Output:# 👤 User contexts:#   client-acme#   demo#   personal#   work (current)Technical Implementation HighlightsWhy Rust?Performance: Instant startup and executionSafety: Memory safety without garbage collectionSingle binary: Easy distribution and installationGreat ecosystem: Excellent CLI libraries like clap and dialoguerArchitecture DecisionsFile-based contexts: Each context is a separate JSON fileAtomic operations: Context switching is done by copying filesState tracking: Current and previous contexts tracked in a hidden state filePlatform compatibility: Works on Linux, macOS, and WindowsSettings Hierarchy Supportcctx respects Claude Code's settings hierarchy while keeping things simple:# Default: user-level contextscctx work# Explicit: project-level contextscctx --in-project staging# Explicit: local project contextscctx --local debugGetting StartedInstallation is straightforward:# From crates.io (recommended)cargo install cctx# Or grab a pre-built binary# Download from https://github.com/nwiizo/cctx/releasesCreate your first contexts:# Create a personal context from current settingscctx -n personal# Create a restricted work contextcctx -n workcctx -e work  # Edit to add restrictions# Start switching!cctx workcctx personalcctx -  # Switch backWhat's Next?The cctx project is actively maintained and follows Claude Code's development closely. Some ideas for the future include:Context templates for common scenariosShell integration for automatic context switchingContext inheritance for shared settingsIntegration with other AI coding toolsConclusioncctx brings the joy of quick context switching to Claude Code users. By focusing on speed, simplicity, and predictable behavior, it removes the friction from managing multiple configurations. Whether you're switching between work and personal projects, managing client-specific settings, or just want better control over your Claude Code permissions, cctx has you covered.The project is open source and available on GitHub. If you find it useful, please consider starring the repository and contributing your own ideas and improvements. Happy context switching!cctx is an independent open-source project and is not affiliated with Anthropic. For official Claude Code documentation and support, please visit docs.anthropic.com.

Introducing cctx: A Context Switcher for Claude Code

はじめにClaude Code 使ってますか？ターミナルから Claude に直接コーディングタスクを投げられる便利なツールなんですが、デフォルト設定のまま使うのはちょっともったいない。というかいちいちいろんなことを聞いてきてめちゃくちゃダルい。syu-m-5151.hatenablog.comsettings.json をちゃんと設定すると、セキュリティも保ちつつ、もっと快適に使えるようになります。全体的に疲れている時の~/.claude/settings.json と~/.claude/CLAUDE.md · GitHub 私のデフォルトの設定も公開してますのでよかったら参考にしてください。ここで読むのをやめる人のために言っておくと Claude Codeの設定は優先順位があるので覚えておくと良い です。あと、比較的に今は黎明期なので非推奨や追加機能が多いのでその点も注意が必要かもです。正直なところ、Anthropic の公式ドキュメント（日本語）が最高に分かりやすいので、まずはそっちを読んでほしいんですが、このブログは公式ドキュメントに赤線を引いたようなもので、実際に使ってみて「これは設定しといた方がいいよ」っていうポイントをピックアップしてまとめました。docs.anthropic.comsettings.json って何？settings.json は Claude Code の動作を制御する設定ファイルです。公式ドキュメントによると、こんな設定ができます。{  "permissions": {    "allow": [      "Bash(npm run lint)",      "Bash(npm run test:*)",      "Read(~/.zshrc)"    ],    "deny": [      "Bash(curl:*)"    ]  },  "env": {    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",    "OTEL_METRICS_EXPORTER": "otlp"  }}設定できる項目 キー  説明  例  apiKeyHelper  Anthropic APIキーを生成するカスタムスクリプト  /bin/generate_temp_api_key.sh  cleanupPeriodDays  チャット記録をローカルに保持する期間（デフォルト：30日）  20  env  すべてのセッションに適用される環境変数  {"FOO": "bar"}  includeCoAuthoredBy  gitコミットにco-authored-by Claudeを含めるか（デフォルト：true）  false  permissions  ツールのアクセス権限設定  後述 権限設定をちゃんとやろうClaude Code の一番重要な機能がこの権限設定。/permissions コマンドで現在の設定を確認できます。/permissionsはとても良いので覚えておいてほしいです。また、便利なCLIの使い方も覚えておいたほうが多分良いです。docs.anthropic.comBash コマンドの制御{  "permissions": {    "allow": [      "Bash(npm run build)",      // 特定のコマンドだけ許可      "Bash(npm run test:*)",     // プレフィックスで許可      "Bash(git:*)"               // git コマンドは全部OK    ],    "deny": [      "Bash(curl:*)"              // curl は使わせない    ]  }}Claude Code はシェル演算子（&&など）も認識してるので、Bash(safe-cmd:*)みたいなルールでもsafe-cmd && dangerous-cmdみたいなのは実行できません。賢い！ファイルアクセスの制御Read と Edit のルールは gitignore の仕様に従います：{  "permissions": {    "allow": [      "Edit(docs/**)",           // プロジェクトの docs ディレクトリ内を編集可能      "Read(~/.zshrc)",         // ホームディレクトリの .zshrc を読める      "Edit(//tmp/scratch.txt)" // 絶対パスは // で指定    ]  }}Web アクセスの制御{  "permissions": {    "allow": [      "WebFetch(domain:example.com)"  // 特定ドメインのみ許可    ]  }}環境変数の活用公式ドキュメントに載ってる環境変数をうまく使うと便利：{  "env": {    "ANTHROPIC_API_KEY": "your-key-here",    "CLAUDE_CODE_ENABLE_TELEMETRY": "0",    "DISABLE_COST_WARNINGS": "1",    "BASH_DEFAULT_TIMEOUT_MS": "300000",    "BASH_MAX_TIMEOUT_MS": "1200000"  }}主要な環境変数 変数名  用途  CLAUDE_CODE_ENABLE_TELEMETRY  テレメトリの有効/無効  DISABLE_COST_WARNINGS  コスト警告を無効化  BASH_DEFAULT_TIMEOUT_MS  Bashコマンドのデフォルトタイムアウト  DISABLE_AUTOUPDATER  自動更新を無効化 設定の優先順位を理解しよう公式ドキュメントによると、設定は以下の順番で適用されます（上が優先）：エンタープライズポリシーコマンドライン引数ローカルプロジェクト設定（.claude/settings.local.json）共有プロジェクト設定（.claude/settings.json）ユーザー設定（~/.claude/settings.json）プロジェクトごとに設定を変えたければ、プロジェクトフォルダに .claude/settings.json を置けばOK。Git で共有したくない設定は .claude/settings.local.json に書こう。実践的な設定例制限的な設定（仕事用）{  "permissions": {    "allow": [      "Bash(npm run lint)",      "Bash(npm run test:*)",      "Bash(git:*)",      "Read(./src/**)",      "Edit(./src/**)"    ],    "deny": [      "Bash(npm publish:*)",      "WebFetch(domain:*)"    ]  },  "includeCoAuthoredBy": false}もう少しゆるい設定（個人用）{  "permissions": {    "allow": [      "Bash(npm:*)",      "Bash(git:*)",      "Bash(cargo:*)",      "Read(**)",      "Edit(~/projects/**)",      "WebFetch(domain:*)"    ]  },  "cleanupPeriodDays": 60}MCP (Model Context Protocol) を使う場合MCP サーバーを使ってる人向けの権限設定：{  "permissions": {    "allow": [      "mcp__puppeteer",                        // puppeteer サーバーの全ツール      "mcp__puppeteer__puppeteer_navigate"     // 特定のツールだけ    ]  }}複数の設定を切り替えたいならちなみに、複数の~/.claude/settings.jsonを簡単に切り替えたい人向けに cctx っていうツールも作ってみました。cargo install cctxまとめClaude Code の settings.json は、ちゃんと設定すると作業効率とセキュリティが大幅に向上します。ちゃんとしましょう。特に重要なのは：権限設定で必要最小限のアクセスだけ許可するプロジェクトごとに適切な設定を使い分ける環境変数でタイムアウトやテレメトリを調整する詳しい設定方法は Anthropic の公式ドキュメント（日本語）がマジで分かりやすいので、ぜひ読んでみてください。Anthropic の公式ドキュメント最高！Claude Code の 公式ドキュメントやベストプラクティス はとりあえず読んだ方がいい。www.anthropic.com参考リンクClaude Code 公式ドキュメント（日本語） - これ読めば全部分かるcctx - Claude Context Manager - 設定切り替えツールClaude Code 設定例（Gist） - 実際の設定例

Claude Code の settings.json は設定した方がいい

はじめに生成AIを使ったコード開発が急速に普及している。GitHub Copilot、ChatGPT、Claude、そして各種IDEに統合されたAIアシスタントや独立したコーディングエージェント。これらのツールは開発効率を飛躍的に向上させ、もはやAIなしでの開発は考えられないという声も聞こえてくる（主に心の底から）。しかし、この革新的な変化の中で、看過できない問題が顕在化している。現在のAIで生成したコードは、2年後の進化したAIで再生成すれば、より効率的で保守性の高いコードに置き換えられる。これ自体は技術進歩として歓迎すべきことだが、重要な情報が失われている。それは「なぜそのコードをそのように実装したのか」という意思決定の記録だ。この問題は単なる技術的な課題ではない。私たちがどのようにソフトウェアを作り、保守し、進化させていくかという、エンジニアリングの本質に関わる問題だ（そして、2年後の自分に恨まれない方法でもある）。プロンプトと成果物の分離がもたらす課題従来の開発では、コードとともにコメントやドキュメントで意図を残してきた。しかしAI時代では、以下の情報が分離してしまう：入力：プロンプト（要件、制約、背景情報）出力：生成されたコード生成されたコードだけがリポジトリに残り、そのコードを生成した際のプロンプトや文脈は失われる。2年後、より優れたAIでコードを改善しようとしても、元の要件や制約条件、設計判断の根拠が不明なため、適切な改善ができない。これは「なんでこんな実装になってるの？」と聞かれて「AIがそう書いたから...」としか答えられない悲しい未来への第一歩だ。ADRからPDRへ：解決策の提案ソフトウェアアーキテクチャの分野では、ADR（Architecture Decision Records）によって設計判断を記録する文化が定着している。同様に、AI時代にはPDR（Prompt Decision Records）が必要だ。syu-m-5151.hatenablog.comPDRに記録すべき要素：使用したAIモデルとバージョン（GPT-4なのかClaude-3なのか、未来の自分は知りたがっている）入力したプロンプトの完全なテキストプロンプトに込めた意図と背景検討した他の選択肢採用した理由とトレードオフ生成パラメータ（temperature、max_tokens等）既存ツールにおける実装例既存ツールの現状についてはこちらがめちゃくちゃよくまとまっております。azukiazusa.devCursor Rulesdocs.cursor.comCursorでは.cursorrulesファイルでプロジェクト固有のコンテキストを定義できる。これにより、AIは常にプロジェクトの規約や方針を理解した上でコードを生成する（理解しているフリをすることもあるが）。具体的には、プロジェクトのルートディレクトリに.cursorrulesファイルを配置することで、以下のような指示を永続化できる：このプロジェクトではTypeScriptを使用し、関数型プログラミングのアプローチを優先する。エラーハンドリングはResult型を使用し、例外は投げない。すべての関数にはJSDocコメントを必須とする。このファイルはプロジェクト全体で共有される暗黙知を形式知化する役割を果たし、新しいメンバーがジョインした際のオンボーディングツールとしても機能する。Cline Rulesdocs.cline.botClineも同様に、プロジェクトルールを定義する仕組みを提供している。これらのルールファイルは、実質的にプロンプトの一部を永続化する仕組みだ。Clineの特徴的な点は、ルールを階層的に管理できることだ。グローバルルール、プロジェクトルール、ディレクトリ固有のルールを定義でき、より細かい粒度でAIの振る舞いを制御できる。例えば：/backendディレクトリ：「APIエンドポイントはRESTfulな設計に従う」/frontendディレクトリ：「ReactコンポーネントはHooksを使用した関数コンポーネントとする」/testsディレクトリ：「テストはAAA（Arrange-Act-Assert）パターンに従う」このようなコンテキストの階層管理により、大規模プロジェクトでも一貫性を保ちながら、部分ごとに最適化されたAI支援を受けられる。Anthropic CLAUDE.mdwww.anthropic.comAnthropicのCLAUDE.mdアプローチは、プロジェクトの全体的なコンテキストを単一のマークダウンファイルにまとめる。これは包括的なプロンプトテンプレートとして機能し、AIとの対話の基盤となる。CLAUDE.mdの強みは、単なるルールの羅列ではなく、プロジェクトのストーリーを語る点にある。典型的な構成は：# プロジェクト概要このプロジェクトの目的と背景# アーキテクチャシステムの全体構成と主要コンポーネントの説明# 開発規約- コーディングスタイル- 命名規則- ディレクトリ構造# よくある質問と回答過去の設計判断とその理由この形式により、AIは単にルールに従うだけでなく、プロジェクトの「なぜ」を理解した上でコードを生成できる。まさに本記事で提唱するPDRの考え方を先取りした実装と言えるだろう。実装における具体的な課題バージョン管理プロンプトもコードと同様にバージョン管理が必要だ。しかし、以下の課題がある：プロンプトの変更がコードに与える影響の追跡AIモデルのバージョンアップに伴う互換性管理プロンプトとコードの紐付けの維持（gitのblameコマンドに「AI」と表示される悲しさ）標準化の欠如現状、プロンプトを記録・管理する標準的な方法は存在しない。各ツールが独自の方法を実装しているため、ツール間での移植性がない。まるで文字コードの乱立時代を彷彿とさせる。再現性の問題同じプロンプトでも、以下の要因により出力が変わる：AIモデルのバージョン生成パラメータAPIのバージョン実行タイミング（モデルの更新）今後の展望と提案短期的な対策既存ツールの活用Cursor、Cline、GitHub Copilotなどが提供するルールファイル機能を積極的に活用し、プロジェクト固有のコンテキストを記録・管理する。プロンプトのコメント埋め込み生成されたコードに、使用したプロンプトをコメントとして埋め込む（将来の自分への手紙として）。専用ディレクトリでの管理/promptsディレクトリを作成し、コードファイルと対応するプロンプトファイルを保存。生成メタデータの記録生成日時、モデルバージョン、パラメータをJSONで保存。中長期的な標準化業界標準として、以下のような仕様が必要になるかもしれない：# prompt-decision-record.yamlversion: 1.0timestamp: 2024-12-XXmodel:  provider: openai  name: gpt-4  version: gpt-4-0125-preview  mood: cooperative  # 冗談ですparameters:  temperature: 0.7  max_tokens: 2000prompt: |  実際のプロンプトテキストcontext:  requirements: |    要件の説明  constraints: |    制約事項  decisions: |    設計判断の根拠output_file: src/feature/***.pyおわりにAI活用が当たり前になる開発環境において、コードの「なぜ」を残すことは、技術的負債を防ぐ重要な実践だ。2年後により良いAIが登場したとき、過去の意思決定を理解できれば、真に価値のある改善が可能になる。私たちエンジニアは、常に未来の自分や同僚のことを考えてコードを書いてきた。可読性、保守性、拡張性—これらはすべて「未来の誰か」のための配慮だ。AI時代においても、この精神は変わらない。むしろ、AIの進化速度を考えれば、より一層重要になる。プロンプトは新しい形の設計書だ。コードレビューと同じように、プロンプトレビューが必要になるかもしれない。リファクタリングと同じように、プロンプトリファクタリングが日常になるかもしれない（プロンプトの可読性を議論する日も近い）。もしくはそのような考慮をすべて超えて全てを理解する生成AIのモデルが成長する可能性もある。PDRのような仕組みの標準化は、AI時代のソフトウェア開発における必須要件となるだろう。エンジニアとして、この課題に真剣に取り組む時期に来ているが、個人ではどうにもならない気もするので。頑張れ、Anthropic！！！

AIが進化しても、なぜそのコードを書いたかは消えていく

なぜmarp.nvimが必要だったのか前回の記事でClaude Codeに移行し、Neovimに完全回帰することを決めた。コーディング、ドキュメント作成、設定ファイルの編集――すべてが再びターミナルで完結するようになった。しかし、一つだけ問題があった。Marpでのプレゼンテーション作成だ。Marpは素晴らしいツールだが、公式のNeovimサポートは存在しない。プレゼンテーションを作るたびに、仕方なくVSCodeやCursorを起動していた。せっかくNeovimに完全回帰したのに、プレゼン作成のためだけに別のエディタを立ち上げる。この矛盾が許せなかった。marp.app既存のソリューションを探したが、満足できるものはなかった。ならば答えは一つ――自作するしかない。こうしてmarp.nvimは生まれた。Neovimですべてを完結させるという理想を、妥協なく追求した結果だ。github.commarp.nvimの技術的アプローチアーキテクチャ┌─────────────┐     ┌─────────────┐     ┌─────────────┐│   Neovim    │────▶│  marp.nvim  │────▶│  Marp CLI   ││   Buffer    │     │  Lua Plugin │     │  --watch    │└─────────────┘     └─────────────┘     └─────────────┘                            │                            ▼                    ┌─────────────┐                    │   Browser   │                    │  Auto-open  │                    └─────────────┘コア実装の詳細1. Marp CLIのプロセス管理これは完全にMarp の作者が優秀なのですがMarpには--watchオプションが存在しています。これを使わない手はないです-- プロセスをバッファごとに管理M.active_processes = {}-- jobstart で Marp CLI を起動local job_id = vim.fn.jobstart(shell_cmd, {    pty = true,  -- 擬似端末で適切な出力キャプチャ    stdout_buffered = false,    stderr_buffered = false,    on_stdout = function(_, data)        -- 出力処理    end,    on_exit = function()        M.active_processes[bufnr] = nil    end})重要なポイント：pty = trueを使用することで、Marp CLIのカラー出力を適切に処理stdout_buffered = falseでリアルタイム出力を実現バッファ番号をキーにしてプロセスを管理2. 自動クリーンアップの実装vim.api.nvim_create_autocmd({"BufDelete", "BufWipeout"}, {    buffer = bufnr,    once = true,    callback = function()        M.stop(bufnr)    end})VSCode拡張機能では当たり前の機能だが、Neovimでは自前実装が必要。バッファのライフサイクルに合わせてプロセスを管理。3. ウォッチモード vs サーバーモードif M.config.server_mode then    cmd = string.format("%s -s '%s'", marp_cmd, file)else    -- デフォルトは --watch モード    cmd = string.format("%s --watch '%s'", marp_cmd, file)end2つのモードをサポート：ウォッチモード（デフォルト）: HTMLファイルを生成し、変更を監視サーバーモード: HTTPサーバーを起動（ポート競合の可能性あり）4. ANSIエスケープシーケンスの処理local function clean_ansi(str)    return str:gsub("\27%[[%d;]*m", ""):gsub("\27%[[%d;]*[A-Za-z]", "")endMarp CLIの美しいカラー出力をNeovimの通知システムで扱うための処理。これがないと文字化けする。実装で工夫した点1. 初回HTML生成の最適化-- ウォッチモード開始前に初回HTMLを生成if not M.config.server_mode then    local init_cmd = string.format("%s '%s' -o '%s'", marp_cmd, file, html_file)    vim.fn.system(init_cmd)        if vim.fn.filereadable(html_file) == 1 then        -- 即座にブラウザを開く        M.open_browser("file://" .. html_file)    endend--watchモードは初回生成が遅いため、事前に生成してUXを改善。2. クロスプラットフォーム対応function M.open_browser(url)    local cmd    if vim.fn.has("mac") == 1 then        cmd = "open " .. url    elseif vim.fn.has("unix") == 1 then        cmd = "xdg-open " .. url    elseif vim.fn.has("win32") == 1 then        cmd = "start " .. url    end    vim.fn.jobstart(cmd, {detach = true})end3. デバッグモードM.config = {    debug = true,  -- 詳細ログを有効化}-- :MarpDebug コマンドで診断function M.debug()    local test_cmd = string.format("%s --version", marp_cmd)    -- Marp CLIの動作確認endトラブルシューティングを容易にするため、詳細なログ出力機能を実装。VSCode拡張機能との機能比較 機能  Marp for VS Code  marp.nvim  ライブプレビュー  ✅  ✅  自動リロード(書き込みイベント時)  ✅  ✅  テーマ切り替え  GUI  :MarpTheme  エクスポート  GUI  :MarpExport  スライドナビゲーション  ✅  ❌（開発中）  スニペット  ✅  ✅  複数ファイル同時編集  ✅  ✅ 使用方法インストール-- lazy.nvim{    "nwiizo/marp.nvim",    ft = "markdown",    config = function()        require("marp").setup({            marp_command = "npx @marp-team/marp-cli@latest",            debug = false,            server_mode = false,  -- ウォッチモードを使用        })    end,}基本的なワークフロー:e presentation.md:MarpWatch          " プレビュー開始(ファイル名をClipboardに書き込みもしている):MarpTheme uncover  " テーマ変更:MarpExport pdf     " PDF出力:q                  " バッファを閉じると自動でサーバー停止トラブルシューティング:MarpDebug          " Marp CLIの動作確認:MarpList           " アクティブなサーバー一覧:MarpStopAll        " 全サーバー停止パフォーマンスと制限事項メモリ使用量Marp CLIプロセス: 約50-100MB/インスタンス複数ファイル同時編集時は線形に増加既知の制限ホットリロードの遅延: ファイル保存からブラウザ更新まで約100-200ms大規模ファイル: 100スライド以上でパフォーマンス低下画像の相対パス: 作業ディレクトリに依存まとめmarp.nvimの開発により、Marpプレゼンテーション作成のためだけにCursorを起動する必要がなくなった。Neovimのjob APIを活用することで、VSCode拡張機能と似た体験を実現できることを証明できた。重要なのは、完璧を求めすぎないこと。VSCode拡張機能のすべての機能を再現する必要はない。ターミナルでの開発に必要十分な機能を、シンプルに実装することが大切だ。Claude Codeとの組み合わせで、プレゼンテーション作成もAIアシスト付きで行える。これで本当にすべての開発作業をNeovimで完結できるようになった。vimmer村への完全帰還、達成。実践Vim　思考のスピードで編集しよう！ (アスキー書籍)作者:Ｄｒｅｗ Ｎｅｉｌ,新丈 径角川アスキー総合研究所Amazon

marp.nvimを開発してCursorから完全移行した話

はじめに前回、「NeovimをCursorのように進化させる - yetone/avante.nvim の導入」を書いた。あの記事では、まるで自分だけの剣を鍛え上げていくように、エディターと共に成長していくPDEの哲学について語った。syu-m-5151.hatenablog.comあれから数ヶ月、私のNeovimはavante.nvimによってCursor + Roo-Codeライクな体験を手に入れ、PDEとしてさらなる進化を遂げた。しかし、告白しなければならないことがある。vimmerを自称しながら、実は日常的にCursorを使っていた。この矛盾と向き合う時が来た。www.cursor.comそして先週の土曜日、私はClaude Codeを使い始めた。今日で1週間。短い期間だが、これが私のPDEに新たな可能性をもたらすことを確信している。そして、Cursor のサブスクを解約してClaude をMAX Planにした。www.youtube.com私は、Claude Code を利用しようと思っているのでvimmer が住む村に帰ろうと思います。一旦、お別れです。 pic.twitter.com/Is5fAUD5hI— nwiizo (@nwiizo) 2025年5月29日   「いいえ、Neovimはもっと強くなれます」前回からの旅路：PDEという哲学前回の記事で、私はこう書いた：Neovimの最大の魅力は、その圧倒的なカスタマイズ性。それは単なるIDE（統合開発環境）ではなく、PDE（Personal Development Environment：個人開発環境）とも呼べる存在です。この言葉は、今思えば預言的だった。PDEという概念は、単にツールをカスタマイズすることではない。それは、開発者が自分自身の思考プロセスと一体化したツールを作り上げることだ。まるで自分だけの剣を鍛え上げていくように、エディターと共に成長していく。そして今、私は気づいた。PDEとは、一人で剣の丘で鉄を鍛つような孤独で崇高な作業なのだと。誰かが用意した完成品ではなく、自分の手で、自分のために、一つ一つ形作っていくもの。avante.nvimは、その第一歩だった。しかし、6ヶ月間Cursor + Roo-Codeを使い込んだことで、私は逆説的にPDEの価値を理解した。Cursor + Roo-Codeは確かに完成度の高い「製品」だ。しかし、私が求めていたのは「作品」—自分の手で育てていけるものだった。実際には育ててなくても育てている感覚があるものだ。正直に告白しよう。vimmerを自称しながらも、実は各所でCursor + Roo-Codeを使っていた。クライアントワークでは生産性を優先してCursor、個人プロジェクトではNeovim。そんな二重生活を送っていた。この矛盾に、私自身も気づいていた。なぜ今、Claude Codeなのか正直に言えば、Claude Codeを使い始めた最大の理由は、Claude Opus 4がリリースされたからだ。最新にして最強のモデル。その能力を、私の愛するターミナル環境で直接使えるなんて—これは試さずにはいられなかった。zenn.devしかし、それだけではない。Claude Codeが掲げる「Terminal Velocity」という概念に、私は強く惹かれた。www.anthropic.com考えてみてほしい。私たちvimmerは、なぜターミナルから離れないのか？それは、思考の流れを断ち切りたくないからだ。GUIアプリケーションへの切り替え、マウスへの手の移動、異なるUIパラダイムへの適応—これらすべてが、私たちの集中を妨げる。Claude Codeは、その問題を根本から解決する。「コンテキストスイッチをゼロにする」—これは、PDEの究極の形かもしれない。そしてもう一つ、個人的に重要だったのがMAX Planという料金体系だ。トークン数無制限。これは貧乏性の私にとって革命的だった。Cursorでは常に「今月あとどれくらい使えるか」を気にしていた。コーディングエージェントでコードを書く前に「これ、AIに聞くほどの価値があるかな？」と躊躇する。そんな心理的ブレーキが、創造性を阻害していたことに気づいた。MAX Planは、その制限から私を解放してくれた。思考のままに、遠慮なくAIと対話できる。まるで無限のメモ帳を手に入れたような感覚だ。「トークンがもったいない」という貧乏性マインドから解放されて初めて、本当の意味でAIとの協働が始まる。これこそが、私のメンタルモデルと完璧に合致した。先週土曜日から使い始めて、まだ1週間。しかし、その短い期間でも、Claude Codeの持つ独特の「控えめな賢さ」に魅了された。Roo-Codeのような積極性はない。しかし、それがかえって心地よい。必要な時に、必要なだけ、的確な支援をしてくれる。Claude Opus 4の高い理解力が、控えめながらも的確なアドバイスを可能にしているのだろう。そして何より、もうトークン数を気にする必要がない。深夜のコーディングセッションで「あと何回質問できるかな...」と計算する必要もない。この精神的な自由度が、私の開発スタイルを根本から変えつつある。zenn.devzenn.devnote.comCursor + Roo-Codeへの敬意、そして決別誤解しないでほしい。私はCursor + Roo-Codeを否定したいわけではない。実際、この6ヶ月間、私は久しぶりにVSCodeベースのCursorをメインエディタとして使い込んだ。そしてそれは、驚くほど素晴らしい体験だった。特にRoo-Codeとの組み合わせで実感したのは、これは単にAIモデルを統合しただけのツールではないということだ。それは開発体験そのものが根本的に違う。github.com考えてみてほしい。従来の開発では、私たちは一つのファイルを開き、一行ずつコードを書いていた。しかしCursor + Roo-Codeの世界では、コードベース全体が一つの有機体として扱われる。「このコンポーネントをリファクタリングして」と言えば、関連する全てのファイルが瞬時に更新される。「このテストを追加して」と言えば、適切なディレクトリに適切な形式でテストが生成される。さらに驚くべきは、Roo-Codeが持つ「意図の理解」だ。曖昧な指示でも、プロジェクトの文脈を読み取り、開発者が本当に必要としているものを推測して提案してくる。それは、経験豊富な同僚とペアプログラミングをしているような感覚だった。これは単なる効率化ではない。これは開発の概念そのものの再定義だった。正直に言えば、これほど生産的な6ヶ月は久しぶりだった。前回の記事でavante.nvimを導入したのも、このCursor + Roo-Codeの革新的な開発体験に触発されたからこそだった。6ヶ月のCursor + Roo-Code体験は、確かに私の開発スタイルを変えた。Tab補完を超えた、AIペアプログラミング。しかし同時に、ある種の違和感も育っていった。それは、自分がコードを「書いている」のか「選んでいる」のか、境界が曖昧になる感覚だった。そして、もう一つの違和感。朝はNeovimで始めたはずが、気がつけばCursorを開いている。締切が迫ると、つい効率的な方を選んでしまう。vimmerとしてのアイデンティティが揺らいでいた。この6ヶ月は、技術的な進歩と同時に、自分自身との葛藤の期間でもあった。Roo-Codeが見せてくれた「開発体験の違い」は革新的だった。しかし、それゆえに気づいたことがある。開発者として長年培ってきた直感が教えてくれる。私たちには「まだ形になっていないアイデアを、コードという形で具現化する」という独特の能力がある。AIはコードを生成できる。しかし、なぜそのコードが必要なのか、それが解決すべき本質的な問題は何かを理解することはできない。そして今、6ヶ月の濃密な体験を経て、私は確信を持って言える—Cursor + Roo-Codeは素晴らしい。その組み合わせは革命的だ。しかし、私にはPDEとしてのNeovimがある。それは単なるエディタではなく、私の思考の延長線上にある道具なのだ。PDEの完成形を目指してしかし、正直に言えば、この6ヶ月はNeovimとCursorの間で揺れ動いていた。月曜の朝は「今週こそNeovimで」と決意するも、水曜には締切に追われてCursorを開く。金曜には罪悪感を感じながらも、Roo-Codeの生産性に頼っていた。vimmerとしての矜持はどこへ行ったのか。だが、この葛藤の中で私は気づいた。PDEとは、単に優れたツールを集めることではない。それは、自分の開発哲学と完全に一致した環境を構築することだ。そして今、NeovimコミュニティはAI時代に適応し、驚くべき進化を遂げている。以下に紹介する3つのプラグインは、その進化の最前線にある。yetone/avante.nvim - 前回の記事で導入したこのプラグインは、Cursor AI IDEの体験をNeovimで完璧に再現する。サイドバーでのAI対話、差分の視覚的表示、ワンクリックでのコード適用など、Cursor + Roo-Codeユーザーが慣れ親しんだ機能をすべて提供する。しかし、それだけではない。Neovimのモーダル編集と完全に統合されているため、思考の流れを妨げることなくAIとの対話を行える。ravitemer/mcphub.nvim - AnthropicのModel Context Protocol (MCP)をNeovimに統合する革新的なプラグイン。MCPサーバーの集中管理により、AIが外部ツールやデータソースにシームレスにアクセスできるようになる。データベースへの直接クエリ、ファイルシステムの操作、外部APIとの連携—これらすべてがNeovimの中で完結する。これこそが、未来のAI開発環境の標準となるだろう。こちらでMCP経由でもclaude-codeを利用している。greggh/claude-code.nvim - Claude Code CLIとNeovimを完全に融合させる野心的なプロジェクト。ターミナル内でClaude Opus 4を含む最新モデルの全能力を解き放ち、まさに「Terminal Velocity」を体現する。:ClaudeCodeコマンド一つで、現在のバッファやプロジェクト全体のコンテキストを理解した上で、最適な提案を行ってくれる。これは単なるプラグインではない—開発体験の再定義だ。これらのツールを組み合わせることで、私のNeovimは単なるテキストエディタから、真のAI統合開発環境へと進化した。もはやCursorを羨む必要はない。むしろ、より深く、より個人的な形でAIと協働できる環境が、ここにある。github.comPDEという哲学の深化PDEとは何か。それは、開発者の思考パターンとツールが完全に一体化した環境だ。前回の記事で初めてこの概念を提示したが、6ヶ月の実践を経て、その意味がより深く理解できるようになった。筆者は専門家ではないため、あくまで個人的な経験に基づく話として聞いていただきたいが、優れたPDEには以下の特徴がある：思考の流れを妨げない：Warp + Neovim + Claude Codeの組み合わせ拡張可能性：新しいツールを取り込める柔軟性個人の哲学の反映：設定ファイルという形での思想の具現化私の~/.config/nvim/lua/plugins/init.luaは、単なる設定ファイルではない。これは私の開発思想の結晶だ。Lazy.nvimを通じて管理されるプラグインの一つ一つが、私の開発哲学を体現している。Cursor + Roo-Codeの体験を経て、その設定はさらに洗練された。そして何より、PDEの構築は一人で剣の丘で鉄を鍛つ行為に似ている。誰も代わりにはできない。自分の手で、自分のために、ひたすら打ち続ける。時に孤独で、時に苦しい。しかし、その先に待っているのは、自分だけの、世界に一つだけの剣だ。Cursor + Roo-Codeが示してくれた新しい開発体験は、確かに革新的だった。しかし、それらは「完成品」だ。一方、PDEとしてのNeovimは「進化し続ける生き物」のようなものだ。私の成長と共に、私の理解と共に、そして私の哲学と共に変化していく。この1週間、Claude Codeを使いながら感じたのは、「これこそが私の求めていたAIとの距離感だ」ということだった。過度に依存せず、しかし必要な時には頼れる。まさに理想的なパートナーシップだ。そして何より、もう環境を使い分ける必要がない。朝から晩まで、クライアントワークも個人プロジェクトも、すべてを私のPDEで完結できる。この統一感が、開発者としての一貫性を取り戻してくれた。おわりに前回の記事から始まった旅は、今、新たな段階に入った。avante.nvimで手に入れたCursor + Roo-Codeライクな体験に、Claude Codeの「Terminal Velocity」が加わることで、私のPDEは更に進化した。興味深いのは、最先端を追求した結果、最も原始的なツール—ターミナルとテキストエディタ—に戻ってきたことだ。しかし、これは後退ではない。これは螺旋的な進化だ。AIとの協働が当たり前になる時代において、私たちに必要なのは、AIとの適切な距離感を保ちながら、共に新たな地平を切り開いていく勇気かもしれない。そして、その第一歩が、自分のPDEを完成させることなのだ。Cursor + Roo-Codeが示してくれた新しい開発体験は、確かに未来の一つの形だ。しかし、それが唯一の答えではない。私たちには、自分自身の開発哲学に基づいて、自分だけの環境を構築する自由がある。「いいえ、Neovimはもっと強くなれます」—この言葉は、単なる願望ではない。それは、PDEという哲学を持つ私たちvimmerの確信なのだ。そして今、Claude Codeの登場により、私はついに二重生活から解放される。もうクライアントワークでCursor、個人でNeovimという使い分けをする必要はない。私のPDEが、すべての開発シーンで通用する強さを手に入れたのだから。そして、PDEの構築とは、一人で剣の丘で鉄を鍛つような営みだ。誰かが用意した剣ではなく、自分の手で打ち、自分の手で研ぎ、自分だけの刃を作り上げる。その過程こそが、私たちを真の開発者にするのかもしれない。この記事を書いている間、私はWarpターミナル上でNeovimとClaude Codeを行き来している。前回のavante.nvim導入から数ヶ月、そして Claude Code導入から1週間。私のPDEは確実に進化した。Lazy.nvimの設定ファイルは公開しているので、興味があれば参考にしてほしい。「Terminal Velocity」を「ターミナルベロシティ」とカタカナ表記したのは、この概念の持つ物理学的な含意—終端速度、つまり最高効率—を日本語でも感じてもらいたかったからだ。「Cursor + Roo-Codeのサブスクリプションを払い続けるか、vimの学習コストを払うか」—これは単なる経済的判断ではない。私たちが開発という行為にどう向き合うか、そしてPDEという哲学をどこまで追求するかという、実存的な選択なのかもしれない。6ヶ月のCursor + Roo-Code体験は本当に素晴らしかった。特にRoo-Codeが示してくれた「開発体験の違い」は、私の開発観を根本から変えた。もしあなたがまだ試していないなら、一度は体験する価値がある。その上で、自分にとっての最適な開発環境を選ぶべきだ。私にとって、それはPDEとしてのNeovimだった。この二重生活は疲れるものだった。.vimrcと.vscode/settings.jsonを行き来し、キーバインドの違いに戸惑い、どちらが本当の自分なのか分からなくなることもあった。しかし、その経験があったからこそ、今の決断に至ることができた。あなたも、vimmer村への帰郷を考えてみてはどうだろうか。Claude Codeという新しい仲間と共に、自分だけのPDEを完成させるために。VimConf 2025 Smallにも行こうかな…。今度こそ、胸を張って「私はvimmerです(え、Neovim ですよね？)」と言えるように。vimconf.org実践Vim　思考のスピードで編集しよう！ (アスキー書籍)作者:Ｄｒｅｗ Ｎｅｉｌ,新丈 径角川アスキー総合研究所Amazon

Claude Code を利用しようと思っているのでvimmer が住む村に帰ろうと思います。

はじめに生成AIが普及して、プログラミングの世界に「バイブコーディング（Vibe Coding）」という面白い言葉が生まれています。なんとなくの感覚や「バイブ(雰囲気)」に頼りながら、AIとやり取りしてコードを作るこの方法は、従来のプログラミングとは全く違うアプローチです。www.gitpod.iolearning.oreilly.com一方で、確率論の世界には「多腕バンディット問題」という古典的な問題があります。限られた時間の中で、どの選択肢が一番良い結果をくれるか分からない状況で、どうやって最良の選択をするか—という問題です。この二つ、一見全く関係なさそうですが、よく観察してみると驚くほど似ています。私たちがAIに色々なプロンプトを試している行動は、実は多腕バンディット問題を解いているのと同じようなことをしているのです。本稿では、この意外な共通点を深く探りながら、日常的なバイブコーディングの中に隠れている、洗練された認知メカニズムの正体に迫ってみたいと思います。注：筆者は多腕バンディット問題の専門家ではないため、解釈に誤りがある可能性があります。あくまで思考実験として読んでいただければと思います。バイブコーディングという新しい認知活動バイブコーディングをしている時、私たちは無意識に以下のようなことをしています：「こういう書き方でプロンプトを書いてみよう」「前回これでうまくいったから、今回も同じパターンでやってみよう」「なんか今日は調子悪いな、違うアプローチを試してみるか」「この例を見せた方が良いコードが出そうだ」興味深いのは、これらの行動が極めて自然に、まるで本能のように現れることです。特別な訓練を受けたわけでもないのに、多くの人が似たような試行錯誤のパターンを示します。www.businessinsider.com多腕バンディット問題多腕バンディット問題を簡単に説明すると：状況： カジノに複数のスロットマシンがあります。それぞれ当たりやすさが違いますが、どれが一番当たりやすいかは分かりません。目標： 限られた時間で、できるだけ多くの当たりを出したい。ジレンマ： 新しいマシンを試して情報を集める（探索）べきか、今まで当たりが多かったマシンをずっと使う（活用）べきか？この「探索と活用のトレードオフ」は、実は生物の進化から人間の日常生活まで、あらゆる場面に現れる根本的な意思決定パターンです。新しいレストランを試すか、お気に入りの店に行くか。新しい本を読むか、好きな作家の作品を読み返すか。私たちは常にこのジレンマと向き合っています。バンディット問題の理論とアルゴリズム (機械学習プロフェッショナルシリーズ)作者:本多淳也,中村篤祥講談社Amazonバイブコーディングをほぼスロットマシンなので...バイブコーディングを多腕バンディット問題として見たとき、その対応関係は驚くほど明確です。「スロットマシン」= プロンプトのパターン「詳しく説明してからコードを書いて」「具体例を示してから実装して」「ステップバイステップで教えて」「エラーハンドリングも含めて書いて」「当たり」= 期待する品質のコードが生成される「探索と活用のジレンマ」= 新しいプロンプト戦略を試すか、慣れ親しんだ方法を使うかしかも、この対応関係は表面的なものではありません。行動パターンの時間的変化、学習曲線、意思決定の心理的メカニズムまで、驚くほど一致しているのです。学習段階の自然な進化初心者期：無制限探索の混沌プログラミングを始めたばかりの人がAIを使う時は、まさに「片っ端から試してみる」状態です。成功率は低いものの、各プロンプトパターンがどれくらい有効かを肌感覚で学習しています。これは多腕バンディット問題における「純粋探索フェーズ」に相当します。中級者期：偏った活用の安定ある程度経験を積むと、「この書き方はいつもうまくいく」という黄金パターンを発見し、それに依存するようになります。これは効率的ですが、より良い戦略を見逃すリスクもはらんでいます。多腕バンディット問題で言う「早期収束の罠」です。上級者期：動的バランスの芸術経験豊富な人は、状況に応じて探索と活用のバランスを直感的に調整します。新しいモデルが出れば探索モードに戻り、安定したタスクでは効率的なパターンを活用します。これは最も洗練された多腕バンディット戦略と言えるでしょう。この自然な進化過程は、特別な理論を学ばなくても、人間が本能的に最適化アルゴリズムを身につけることを示しています。コンテキストによる戦略の分化興味深いことに、プログラミング言語やAIモデルが変わると、最適なプロンプト戦略も変化します。Pythonでうまくいくアプローチが、C++では効果的でない。GPT-4で成功した方法が、Claude では通用しない。これは多腕バンディット問題における「コンテキスト付きバンディット」の典型例です。同じ「腕」（プロンプトパターン）でも、文脈によって期待報酬が変わるのです。熟練したエンジニアは、この文脈の切り替えを無意識に行います。言語を変えると同時に、プロンプト戦略も自動的に調整される。これは、人間の適応的学習能力の驚くべき柔軟性を物語っています。「報酬」の多次元性と測定の難しさバイブコーディングにおける「報酬」は、多腕バンディット問題の古典的な設定よりもはるかに複雑です。即座に測定できる報酬コンパイルが通る期待した動作をする実行時間が短い長期的な報酬コードの可読性保守のしやすさチーム開発での再利用性主観的な報酬「美しい」コード学習になるコード創意工夫のあるコードこの多次元的な報酬構造が、バイブコーディングを単純な最適化問題以上の、芸術的な活動にしているのかもしれません。自動テストが変革する「報酬関数」ここで自動テストの存在が、バイブコーディングの性質を根本的に変えることに注目したいと思います。テストがない状況では、報酬の測定は主観的で曖昧です。「なんとなく動いているから良いコード」という判断は、多腕バンディット問題で言う「ノイズの多い報酬シグナル」です。一方、自動テストがある場合、報酬は明確で客観的になります。「全テストが通る」は0か1かの明確な成功指標です。これにより、どのプロンプト戦略が本当に効果的かを正確に学習できるようになります。この変化は単なる測定精度の向上以上の意味を持ちます。報酬関数の明確化により、学習アルゴリズムそのものが高度化するのです。syu-m-5151.hatenablog.comプロンプトエンジニアリングという「期待値制御」プロンプトエンジニアリングを多腕バンディット問題の視点で見ると、これは「各腕の期待報酬を高める技術」と解釈できます。曖昧なプロンプト「ログイン機能を作って」は、期待報酬の分散が大きい「腕」です。うまくいく時もあれば、全く期待外れの結果になることもある。一方、詳細で構造化されたプロンプトは、期待報酬の平均値を高め、分散を小さくします。これは多腕バンディット問題において、明らかに優位な「腕」です。興味深いのは、多くの人がプロンプトエンジニアリングの重要性を、理論を知らずとも実感していることです。これは、人間が直感的に「期待値と分散の最適化」を理解していることを示唆しています。チーム協働における「集合知のバンディット」個人でのバイブコーディングから、チームでの協働に視点を移すと、さらに興味深い現象が見えてきます。複数のエンジニアが異なる「腕」を並行して探索し、成果を共有する。これは「協調型バンディット」と呼ばれる高度な問題設定です。全員が同じ試行錯誤を繰り返す無駄を避け、チーム全体として効率的に最適解に近づいていきます。「このプロンプトパターンが効果的だった」「このアプローチは避けた方がいい」こうした情報共有は、個人の学習速度を遥かに超える集合的な最適化を可能にします。人間が本能的に行う知識共有行動が、実は数学的に最適な協調戦略だったのです。AIモデル進化への適応：非定常環境での生存戦略AIモデルの頻繁なアップデートは、バイブコーディングに非定常性という新たな次元を加えます。昨日まで最適だった戦略が、新しいモデルでは全く効果がない。これは生物の進化圧にも似た、動的な環境変化です。この変化に対して、経験豊富なエンジニアは見事な適応を見せます。新しいモデルが出ると、自動的に「探索モード」に切り替わる。過去の成功体験にとらわれず、新たな最適解を求めて試行錯誤を始める。この柔軟性は、多腕バンディット問題の理論が想定する以上の高度な適応能力です。環境の変化を察知し、学習戦略そのものを動的に調整する—これは人間の認知能力の真骨頂と言えるでしょう。「バイブ」の正体：統計的直感の結晶「バイブ」や「勘」と呼ばれる現象の正体を、多腕バンディット問題の枠組みで考えてみると、驚くべき洞察が得られます。経験豊富なエンジニアが「なんとなくこのアプローチが良さそう」と感じる時、それは過去の膨大な試行錯誤から蓄積された統計的パターンの内在化です。意識的には覚えていない微細な成功・失敗の記憶が、直感的判断として表面化している。これは、Thompson Samplingという高度なアルゴリズムと本質的に同じメカニズムです。過去の経験から各戦略の成功確率分布を学習し、その分布に基づいて確率的に選択を行う。完全に論理的でもなく、完全にランダムでもない、絶妙なバランスの意思決定です。「バイブ」は非科学的なものどころか、むしろ最先端の確率的アルゴリズムを人間が自然に実装している証拠なのです。中毒性の数学的説明バイブコーディングに多くの人が「ハマる」理由も、多腕バンディット問題の枠組みで説明できます。新しいプロンプトを試すたびに得られる「うまくいくかもしれない」という期待感。実際に良いコードが生成された時の達成感。これらは、不確実性の中で最適解を探索する過程で得られる本能的な報酬です。人間の脳は、探索と活用のバランスを取る活動に対して、進化的に報酬を与えるよう設計されています。バイブコーディングがこの古い報酬系を刺激するからこそ、多くの人が夢中になるのでしょう。なぜこの類似性が存在するのかここで根本的な問いに向き合ってみましょう。なぜバイブコーディングと多腕バンディット問題は、これほどまでに似ているのでしょうか？一つの仮説は、人間の学習と意思決定の根底にある共通のメカニズムです。不確実な環境で最適な選択を見つけるという課題は、人類が何十万年もの間直面してきた生存問題でした。どの狩場が豊富な獲物をもたらすか。どの植物が安全で栄養価が高いか。多腕バンディット問題は、この根本的な生存戦略を数学的に抽象化したものです。そして、バイブコーディングは、この古い学習メカニズムが新しい技術的環境で発現したものなのかもしれません。イプシロン-グリーディ戦略としての日常多くのエンジニアが無意識に実践している行動パターンを詳しく観察すると、「イプシロン-グリーディ戦略」との類似性が見えてきます：大部分の時間（90%）: 今まで最も成功率の高かった方法を使う（活用）少しの時間（10%）: 新しい方法を試してみる（探索）「いつものパターンでやってみよう。あ、でもたまには違うアプローチも試してみるか」この何気ない意思決定が、実は数学的に洗練された最適化戦略だというのは、驚くべき発見です。UCB的思考の高次元化より洗練された判断をする人は、UCB（Upper Confidence Bound）アルゴリズムに似た思考を示します：「このプロンプトは過去に良い結果を出したけど、まだ試行回数が少ないから、もう少し試してみる価値がある」これは、平均的な成功率だけでなく、「不確実性」も考慮した意思決定です。試行回数が少ない選択肢に対して「まだ可能性がある」という判断を下す。この高次な推論を、多くの人が自然に行っているのです。認知バイアスとしての「過度な活用」一方で、バイブコーディングには多腕バンディット問題と同様の落とし穴もあります。早期収束の罠: 最初に見つけた成功パターンに固執し、より良い方法を探索しなくなる。確証バイアス: 自分のお気に入りの方法がうまくいった事例ばかりを記憶し、失敗例を忘れてしまう。環境変化への適応遅れ: 新しいAIモデルが出ても、古い戦略に固執し続ける。これらの認知バイアスは、多腕バンディット問題における「準最適解への収束」と本質的に同じ現象です。人間の学習メカニズムの限界が、両方の文脈で同様に現れているのです。思考実験から見えてくることこの思考実験から得られる洞察を、整理してみましょう。第一に、私たちが日常的に行っている「試行錯誤」は思っているより合理的だということです。「なんとなく」でプロンプトを選んでいるように見えて、実は過去の経験から学習した効率的な戦略を使っているのです。第二に、自動テストやプロンプトエンジニアリングが効果的な理由が、多腕バンディット問題の観点から説明できることです。これは単なる「ベストプラクティス」ではなく、学習効率を上げる合理的な手法だったのです。第三に、チームでのAI活用が個人より効果的な理由も明確になります。みんなで情報共有することで、効率的に最適解を見つけられる。これは感覚的に分かっていたことですが、理論的な裏付けがあったということです。エンジニアとしての実感実際にバイブコーディングをしている身として、この類似性には「なるほど、そういうことか」という納得感があります。新しいプロジェクトを始める時の「色々試してみる」段階、ある程度慣れてきて「いつものパターン」を使うようになる段階、そして新しいAIモデルが出ると再び「探索モード」に戻る段階。この流れは、多くのエンジニアが体験していることでしょう。特に興味深いのは、「なんか今日は調子悪いな」と感じて戦略を変える時の判断です。これも、実は環境の変化を察知した合理的な適応行動だった可能性があります。おわりにこの思考実験の面白さは、日頃「感覚的」だと思っていた行動に、実は理論的な構造があったという発見にあります。「バイブ」と呼んでいた直感は、決してランダムな当て推量ではありませんでした。それは、過去の大量の試行錯誤から学習した、効率的な意思決定メカニズムのように思えます。私たちがAIに向かって何気なくプロンプトを打っている時、実は無意識のうちに確率的な最適化を行っている。理論を知らなくても、効果的な学習戦略を実践している。この発見は、バイブコーディングをただの「なんとなくのコーディング」から、理論に裏打ちされた合理的なアプローチとして捉え直すきっかけを与えてくれます。最終的に、この思考実験が示しているのは、私たちエンジニアが思っているより賢く、効率的に学習し、適応しているということです。それは決して特別なことではなく、人間が持つ自然な学習能力の現れなのかもしれません。

【思考実験】バイブコーディング(Vibe coding)と多腕バンディット問題 - 選択の最適化と報酬の探索

これから伸びるエンジニア職とは？  - AI時代に市場価値を高めるキャリア戦略 @エンジニア業界セミナー in 会津大学

ブログ記事評価プロンプト (0.0-5.0)を作成しました。

RustのWebアプリケーションにオブザーバビリティを実装するインフラエンジニアのための入門ガイド

本日、Forkwell さんに悪ふざけに付き合ってもらってイベントやりました。ありがとうございます。「転職したらMCPサーバーだった件」 🎵🧭 というタイトルで登壇しました！🔍 イベント詳細:- イベント名: 転職したらMCPサーバーだった件- 公式URL: https://forkwell.connpass.com/event/354289/- ハッシュタグ: https://x.com/search?q=%23Forkwell_MCP&f=live- 参考資料①: https://speakerdeck.com/nwiizo/kokohamcpnoye-ming-kemae- 参考資料②: https://syu-m-5151.hatenablog.com/entry/2025/03/09/020057- 参考資料③: https://speakerdeck.com/superbrothers/that-time-i-changed-jobs-as-a-kubernetes

転職したらMCPサーバーだった件

中学17年生

MCP-Useとは何か？MCP-Use (Model Context Protocol - Use) は、LLM（大規模言語モデル）とMCPサーバーの間の橋渡しをするPythonライブラリです。このライブラリにより、OpenAI、Anthropic、Groqなど様々なLLMプロバイダーのモデルに、Webブラウジングやファイル操作といった外部ツールへのアクセス権を付与できます。github.com環境構築：uvの活用今回はRustベースの高速パッケージマネージャーuvを使って環境を構築します。docs.astral.sh# 仮想環境を作成uv venv# 仮想環境をアクティベートsource .venv/bin/activate.fish  # fishシェル使用時# 必要なパッケージをインストールuv pip install "mcp-use[dev,anthropic,openai,search]"uv pip install fastembeduv pip install python-dotenv langchain-openai従来のpipと比較してuvは大幅に高速で、特に複雑な依存関係を持つプロジェクトではその差が顕著です。MCP-Useはさまざまな依存関係を持つため、uvの使用が特に有効です。MCP-Useの基本構造MCP-Useの中核は以下のクラスから構成されています：MCPClient: 設定ファイルからMCPサーバーへの接続を管理MCPAgent: LLMとMCPサーバーを組み合わせてタスクを実行各種アダプター: LLMプロバイダーとMCPサーバー間の変換処理実装例：ウェブ情報取得エージェント今回はMCP-Useを使って、特定のWebサイトから情報を抽出するエージェントを構築します。import asyncioimport osfrom dotenv import load_dotenvfrom langchain_openai import ChatOpenAIfrom mcp_use import MCPAgent, MCPClientasync def main():    # 環境変数を読み込み    load_dotenv()    # 設定ファイルからMCPClientを作成    client = MCPClient.from_config_file(        os.path.join(os.path.dirname(__file__), "browser_mcp.json")    )    # LLMを初期化    llm = ChatOpenAI(model="gpt-4o")        # エージェントを作成    agent = MCPAgent(llm=llm, client=client, max_steps=30)    # クエリを実行    result = await agent.run(        "3-shake.com にアクセスして株式会社スリーシェイクのCEOのxアカウントを教えて下さい",        max_steps=30,    )    print(f"\nResult: {result}")if __name__ == "__main__":    asyncio.run(main())以下、各部分の詳細を解説します。1. MCPClient初期化とその内部構造client = MCPClient.from_config_file(    os.path.join(os.path.dirname(__file__), "browser_mcp.json"))MCPClientクラスはMCPサーバーへの接続を管理します。from_config_fileメソッドで設定ファイルから構成を読み込みます。設定ファイルbrowser_mcp.jsonの中身は以下のようになっています：{  "mcpServers": {    "playwright": {      "command": "npx",      "args": ["@playwright/mcp@latest"],      "env": {        "DISPLAY": ":1"      }    }  }}この設定は、PlaywrightをMCPサーバーとして使用することを指定しています。MCPClientはこの設定を読み込み、以下の処理を実行します：設定に基づいて適切なコネクタ（この場合はStdioConnector）を作成コネクタを使ってPlaywright MCPサーバーとの通信チャネルを確立初期化処理を実行し、利用可能なツールの一覧を取得内部的には、MCP-Useは非同期処理を多用しており、asyncioを活用した効率的な通信を実現しています。2. LLMの初期化と統合llm = ChatOpenAI(model="gpt-4o")MCP-UseはLangChainとシームレスに統合されており、様々なLLMプロバイダーのモデルを使用できます。今回はOpenAIのGPT-4oを使用していますが、以下のように簡単に切り替えることも可能です：# Anthropicのモデルを使用する場合from langchain_anthropic import ChatAnthropicllm = ChatAnthropic(model="claude-3-5-sonnet-20240620")# Groqのモデルを使用する場合from langchain_groq import ChatGroqllm = ChatGroq(model="llama3-8b-8192")MCP-Useの内部では、LangChainAdapterクラスがLLMとMCPサーバー間の変換処理を担当し、ツールの記述をLLMが理解できる形式に変換しています。3. MCPAgentの作成と実行agent = MCPAgent(llm=llm, client=client, max_steps=30)MCPAgentクラスは、LLMとMCPクライアントを組み合わせてタスクを実行するための中核コンポーネントです。主なパラメータは：llm: 使用するLLMモデルclient: MCPクライアントインスタンスmax_steps: エージェントが実行できる最大ステップ数max_stepsパラメータは特に重要で、タスクの複雑さに応じて適切な値を設定する必要があります：- 単純な情報検索: 5-10ステップ- 複数ページの探索: 15-20ステップ- 複雑な操作: 25-30ステップ4. タスク実行の内部処理result = await agent.run(    "3-shake.com にアクセスして株式会社スリーシェイクのCEOのxアカウントを教えて下さい",    max_steps=30,)agent.run()メソッドが呼び出されると、以下の処理が実行されます：指定されたクエリをLLMに送信し、実行プランを生成LLMが適切なツールを選択し、その実行をリクエストMCPクライアントがツールのリクエストをMCPサーバーに転送MCPサーバーがツールを実行し、結果を返す結果をLLMに返し、次のステップを決定最終的な回答が生成されるまで、ステップ2-5を繰り返す内部的には、この処理はMCPAgent.run()メソッド内の_agent_executor._atake_next_step()メソッドで実装されています。

MCP-Use を使っていきます

本日、「AI駆動開発実践の手引き -これが僕/私のAI（アイ）棒」というイベントで「ここはMCPの夜明けまえ」 🎵🧭 というタイトルで登壇しました！🔍 イベント詳細:- イベント名: 【ハイブリッド開催】AI駆動開発実践の手引き -これが僕/私のAI（アイ）棒-- 公式URL: https://hack-at-delta.connpass.com/event/350588/📝 登壇ブログ- 2025年4月、AIとクラウドネイティブの交差点で語った2日間の記録 #CNDS2025 #hack_at_delta- https://syu-m-5151.hatenablog.com/entry/2025/04/24/113500

ここはMCPの夜明けまえ

こんにちは皆さん！本日はCloud Native Daysのプレイベントで登壇させていただきます。2019年以来の登壇となりますが、当時はまだ肩こりなんて無縁だったんですよね…。時の流れは容赦ないもので、最近の肩こりが辛くて昨日も整骨院に通ってきました。30分の持ち時間に対してスライドが80枚以上という暴挙にも出ています。---本日、「CloudNative Days Summer 2025 プレイベント」というイベントで「生成AIによるCloud Native 基盤構築の可能性と実践的ガードレールの敷設について」 🎵🧭 というタイトルで登壇しました！🔍 イベント詳細:- イベント名: CloudNative Days Summer 2025 プレイベント- 公式URL:https://cloudnativedays.connpass.com/event/351211/ - イベントのURL: https://event.cloudnativedays.jp/cnds2025📝 登壇ブログ- 2025年4月、AIとクラウドネイティブの交差点で語った2日間の記録 #CNDS2025 #hack_at_delta- https://syu-m-5151.hatenablog.com/entry/2025/04/24/113500

生成AIによるCloud Native基盤構築の可能性と実践的ガードレールの敷設について

本日、「Kubernetesで実践する Platform Engineering - FL#88」というイベントで「Kubernetesで実現できるPlatform Engineering の現在地」🎵🧭 というタイトルで登壇しました！🔍 イベント詳細:- イベント名: Kubernetesで実践する Platform Engineering - FL#88- 公式URL: https://forkwell.connpass.com/event/348104/🗣️ 関連スライド- インフラをつくるとはどういうことなのか、 あるいはPlatform Engineeringについて- https://speakerdeck.com/nwiizo/inhurawotukurutohadouiukotonanoka-aruihaplatform-engineeringnituite- Platform Engineeringは自由のめまい- https://speakerdeck.com/nwiizo/platform-engineeringhazi-you-nomemai

Kubernetesで実現できるPlatform Engineering の現在地

こんにちは、花粉症が辛いです。登壇する時にくしゃみしないために朝から外出を自粛してます。15分なのにスライドが40枚あります。本日、「信頼性向上の第一歩！～SLI/SLO策定までの取り組みと運用事例～」というイベントで「SLI/SLO・ラプソディあるいは組織への適用の旅」🎵🧭 というタイトルで登壇しました！🔍 イベント詳細:- イベント名: 信頼性向上の第一歩！～SLI/SLO策定までの取り組みと運用事例～- 公式URL: https://findy.connpass.com/event/345990/📚 さらに！4日後の3月25日には翻訳した書籍に関する登壇する別イベントもあります！😲「Kubernetesで実践する Platform Engineering - FL#88」🐳⚙️興味がある方はぜひ参加してください！👨‍💻👩‍💻👉 https://forkwell.connpass.com/event/348104/お見逃しなく！🗓️✨

SLI/SLO・ラプソディあるいは組織への適用の旅

2025年02月13日 Developers Summit 2025 13-E-4 にて「インフラをつくるとはどういうことなのか、 あるいはPlatform Engineeringについて - Platform Engineeringの効果的な基盤構築のアプローチ」というタイトルで登壇します。同日にPFEM特別回 でも登壇するのですが資料頑張って作ったのでそっちも読んでください。完全版は機会があればお話するので依頼してください。イベント名:  Developers Summit 2025公式URL: https://event.shoeisha.jp/devsumi/20250213セッションURL: https://event.shoeisha.jp/devsumi/20250213/session/5546登壇ブログ: https://syu-m-5151.hatenablog.com/entry/2025/02/14/071127

インフラをつくるとはどういうことなのか、 あるいはPlatform Engineeringについて

2025年02月13日 Kubernetesで実践するPlatform Engineering発売記念！ PFEM特別回にて「Platform Engineeringは自由のめまい - 技術の選択における不確実性と向き合う」というタイトルで登壇します。同日にDevelopers Summit 2025 でも登壇したのですが資料頑張って作ったのでそっちも読んでください。イベント名: Kubernetesで実践するPlatform Engineering発売記念！ PFEM特別回公式URL: https://platformengineering.connpass.com/event/342670/登壇ブログ: https://syu-m-5151.hatenablog.com/entry/2025/02/14/071127

Platform Engineeringは自由のめまい 

2025年01月26日 10:35-11:05（ルーム A）にて「Site Reliability Engineering on Kubernetes」というタイトルで登壇します。イベント名: SRE Kaigi 2025公式URL: https://2025.srekaigi.net/セッションURL: https://fortee.jp/sre-kaigi-2025/proposal/a75769d1-7835-4762-a1f6-508e714c8c8e登壇ブログ: https://syu-m-5151.hatenablog.com/entry/2025/01/26/005033

Site Reliability Engineering on Kubernetes

2024年16:20-17:00（Track A）にて「メインテーマはKubernetes」というタイトルで登壇します。イベント名: Cloud Native Days Winter 2024公式URL:https://event.cloudnativedays.jp/cndw2024/セッションURL:https://event.cloudnativedays.jp/cndw2024/talks/2373

メインテーマはKubernetes

2024年11月06日(水) 18:00～19:00の予定に遅刻してしまい、大変申し訳ございませんでした。お詫びとして、当初非公開予定であった資料を公開させていただきます。元々、公開する予定ではなかったので補足が足りない部分などあると思いますのでご容赦下さい。ブログなどで補足情報出すかもなので気になればフォローしてください- https://syu-m-5151.hatenablog.com/- https://x.com/nwiizoSREの前に - 運用の原理と方法論公式URL: https://talent.supporterz.jp/events/2ed2656a-13ab-409c-a1d9-df8383be25fd/

SREの前に

Cloud Operator Days 2024 クロージングイベントhttps://cloudopsdays.com/closing/とても、端的に言うと「プロンプトエンジニアリングをしよう」って話。この発表資料は、LLM（大規模言語モデル）によるIT運用の可能性と課題を探っています。AIOpsの概念を基に、LLMがインシデント対応、ドキュメンテーション、コード分析などの運用タスクをどのように改善できるかを説明しています。同時に、LLMの「幻覚」や不完全性といった課題も指摘し、適切な利用方法やプロンプトエンジニアリングの重要性を強調しています。登壇時ブログhttps://syu-m-5151.hatenablog.com/entry/2024/09/06/154607

2024年版 運用者たちのLLM

Platform Engineering とSREの門 というタイトルで登壇しました。入門のタイポではありません。イベント名: Platform Engineering Kaigi 2024イベントURL:https://www.cnia.io/pek2024/登壇ブログ:『Platform Engineering とSREの門』という間違ったみたいなタイトルで登壇しました。 #PEK2024https://syu-m-5151.hatenablog.com/entry/2024/07/09/215147

Platform Engineering と SRE の門 

運用者の各領域で向き合うLLM というタイトルで登壇しました。イベント名: Cloud Operator Days Tokyo 2024 イベントURL:https://cloudopsdays.com/

運用者の各領域で向き合うLLM

可観測性ガイダンスというタイトルで登壇してきました。イベント名: オブザーバビリティ再入門 - 大切さと高め方を知ろう！イベントURL: https://mackerelio.connpass.com/event/316449/# ブログでいくつかの可観測性に関する書籍のまとめを投稿しました。5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文https://syu-m-5151.hatenablog.com/entry/2024/04/16/180511もう一度読むObservability Engineeringhttps://syu-m-5151.hatenablog.com/entry/2024/05/06/090014盲目的に始めないためのオブザーバビリティ実践ガイド - Cloud Observability in Actionの読書感想文https://syu-m-5151.hatenablog.com/entry/2024/05/10/121047

可観測性ガイダンス

書を捨てよ、現場へ出よう このSRE本がすごい！2024年 LT版というタイトルで登壇してきました。SREたちの廊下〜あなたの現場での悩み、あの本にヒントがあるかも〜https://findy.connpass.com/event/311323/元ブログはこちらこのSRE本がすごい！2024年版https://syu-m-5151.hatenablog.com/entry/2024/01/26/165255登壇ブログはこちら『読書とは、能力、知識ではなく 問いを獲得するための行為』みたいな内容で登壇しました。https://syu-m-5151.hatenablog.com/entry/2024/03/13/164951

書を捨てよ、現場へ出よう

「Dapr の概念と実装から学ぶ Observability への招待」 というタイトルで登壇します。https://event.cloudnativedays.jp/o11y2022/talks/1382:embed:cite セッション概要Dapr は CloudNative な技術を背景に持つ分散アプリケーションランタイムです。本セッションでは Dapr の Observability に関する各種機能と、その実装について解説していきます。さらにスリーシェイクの Dapr と Observability への取り組みに関してもご紹介します。Dapr の機能でカバーできる点...