nwiizo

RustのDockerfile、2025年はこれでいこう

cargo-watch、やめるってよRustを書いてると、気づくんですよね。保存ボタンを押すたび、手動でcargo checkとかcargo testとか叩いてる自分に。「あれ、俺って原始人だっけ？」みたいな気持ちになる。そこで救世主として現れたのがcargo-watchだったわけです。過去形。github.comそう、cargo-watchはもうメンテされてないんです。引退しちゃった。ここで一旦、真面目な話を。10年以上もcargo-watchとwatchexecっていうOSSプロジェクトを守り続けてきたFélix Saparelliさんに、心から敬意と感謝を。あなたのおかげで、世界中の無数のRust開発者が「あ、これ便利じゃん」って生産性爆上げできたんです。本当にありがとうございました。で、公式READMEには作者本人がこう書き残してる。"It's time to let it go. Use Bacon. Remember Cargo Watch."なんかもう、エモすぎません？10年以上続いたプロジェクトが、バトンを次世代に渡して静かに去っていく感じ。その後継者がbacon。そして汎用性の塊みたいなwatchexec。ベーコンって名前、朝ごはん感あるけど、これが本当にすごいんですよ。というわけでこの記事では、Rust開発で使えるファイル監視ツールについて解説していきます。cargo-watchロス、今日で終わりにしましょう。baconって何？baconは、Rust専用に作られたバックグラウンドコードチェッカーです。エディタの隣で動かしておくと、ファイルを保存するたびに自動でコンパイルチェックを走らせて、エラーや警告をリアルタイムで表示してくれます。github.comcargo-watchとの違いcargo-watchの作者が「baconこそが自分の理想だった」と語っているほど、baconは進化しています。TUIで見やすい - エラーが警告より先に表示され、スクロール不要キーボード操作 - tでテスト、cでClippy、dでドキュメントと一瞬で切り替え小さい画面でも快適 - ターミナルのサイズに合わせて表示を最適化Rust Analyzerと競合しない - 開発体験がスムーズインストール# 基本インストールcargo install --locked bacon# オプション機能も入れる（クリップボード、サウンド）cargo install --locked bacon --features "clipboard sound"基本的な使い方プロジェクトのルートでbaconを起動するだけ。cd your-rust-projectbaconデフォルトではcargo checkが走ります。ファイルを保存すると自動で再チェック。主要なキーボードショートカットbaconの真価はキーボードショートカットにあります。t - テスト実行に切り替えc - Clippyに切り替えd - ドキュメントをブラウザで開くf - テスト失敗時、そのテストだけに絞り込みEsc - 前のジョブに戻るCtrl+j - すべてのジョブ一覧を表示h - ヘルプ表示q - 終了特定のジョブで起動# テストを監視bacon test# Clippyを監視bacon clippy# 厳格なClippyルール（pedantic）bacon pedantic# 高速テストランナー（nextest）bacon nextest# すべてのターゲットをチェックbacon check-all# 特定のジョブを指定bacon --job my-custom-jobbacon.toml で設定をカスタマイズプロジェクトに合わせてジョブを定義できます。# 設定ファイルを生成bacon --init設定例# bacon.toml# Windows向けのチェック[jobs.check-win]command = ["cargo", "check", "--target", "x86_64-pc-windows-gnu"]# 厳しめのClippy[jobs.clippy-strict]command = [    "cargo", "clippy", "--",    "-D", "warnings",    "-A", "clippy::collapsible_if",]need_stdout = false# サンプルをチェック[jobs.check-examples]command = ["cargo", "check", "--examples", "--color", "always"]watch = ["examples"]  # srcは自動で監視される# 実行ジョブ[jobs.run]command = ["cargo", "run"]allow_warnings = trueneed_stdout = true# キーバインディングのカスタマイズ[keybindings]shift-c = "job:clippy-strict"r = "job:run"設定しておいてよいことドキュメントを素早く確認[jobs.doc-open]command = ["cargo", "doc", "--no-deps", "--open"]need_stdout = falseon_success = "back"  # ドキュメントが開いたら前のジョブに戻る長時間実行するアプリケーション[jobs.server]command = ["cargo", "run"]allow_warnings = trueneed_stdout = truebackground = falseon_change_strategy = "kill_then_restart"watchexecとの使い分けbaconはRust専用ですが、watchexecは汎用的なファイル監視ツールです。github.comwatchexecを使うべき場合# インストールcargo install watchexec-cli# 基本的な使い方watchexec --restart cargo run# 特定の拡張子だけ監視watchexec -e rs,toml cargo test# デバウンス設定watchexec -d 2000 cargo checkwatchexecが向いているケース：- Rust以外の言語やツール- シェルスクリプトの実行- rsyncなどの同期処理- より細かい制御が必要な場合# 例：TypeScriptのビルドwatchexec -e ts,tsx npm run build# 例：ファイル同期watchexec -w src -- rsync -avhP ./src/ ./backup/実践的なワークフロー開発時のセットアップターミナルを分割左：Vim/Neovim右上：bacon右下：通常のシェル私はWarpを使ってペイン分割している。baconの起動bacon  # デフォルトでcheckが走るコードを書く保存すると自動でチェックエラーがあれば即座に表示エラーが消えたらClippyの警告が見えるテストを書くtキーでテストモードに切り替え失敗したらfで絞り込み修正したらEscで全テストに戻る最終チェックcキーでClippyの提案を確認コード品質を向上ちょっとしたTipsシェルエイリアスで効率化頻繁に使うコマンドをエイリアス化すると便利です。# ~/.zshrc または ~/.bashrc に追加alias bac='bacon'alias bacc='bacon clippy'alias bact='bacon test'alias bacp='bacon pedantic'watchexecで複数パスを監視# srcとtestsディレクトリの.rsと.tomlファイルを監視watchexec -e rs,toml -w src -w tests -- cargo testVim/Neovimとの連携nvim-bacon プラグインbaconの診断結果をNeovimに統合するプラグインがあります。github.com" lazy.nvim の場合{  'Canop/nvim-bacon',  config = function()    require('bacon').setup()  end}主な機能は以下の通り。エラー箇所へのジャンプQuickfixへの統合:Bacon コマンドでbaconを起動:BaconLoad で診断結果を読み込み補足：VS Code向けVS Codeユーザーの場合は、bacon-lsというLanguage Serverが利用可能です。まとめcargo-watchの時代は終わりました。でも、より良いツールが生まれています。こう使い分けよう：Rust開発 → bacon一択TUIが快適キーボードだけで完結設定ファイルで柔軟にカスタマイズそれ以外 → watchexec汎用的に使えるシンプルで強力シェルスクリプトとの相性抜群baconを知らずにRustを書いていた人は、今すぐ試してください。開発体験が一段階レベルアップします。cargo install --locked baconcd your-projectbaconたったこれだけ。あとはコードを書くだけです。参考リンク：- bacon公式サイト- watchexec GitHub- cargo-watch（アーカイブ済み）

baconを知らずにRust書いてた

文章力を分解してちゃんと文章を書く。

読解力を分解してちゃんと文章を読む。

生成AI時代に必要なコンサルタントの秘密

システム思考を使う人が知っておいてよい12のシステムアーキタイプ

システム思考を日々の開発に取り入れる実践ガイド

システムを作る人がまず理解すべきシステム思考の基礎

2025年9月30日（火）、「バイブコーディングもくもく会 #03」というイベントで登壇することになった。https://aimokumoku.connpass.com/event/368935/正直に言うと、このイベントがどんな空気感なのか、まだ全然掴めていない。ゆるい感じなのか、ガチな感じなのか。笑いを取りに行くべきなのか、真面目にやるべきなのか。そういう「場の空気」みたいなものが事前に分からないのは、けっこう怖い。だから、とりあえず色々なパターンを想定して準備している。要するに、どんな状況になっても対応できるように、という保険をかけまくっているのだ。我ながら、慎重すぎるかもしれない。ブログとGithubはこちら。https://syu-m-5151.hatenablog.com/https://github.com/nwiizo一応、置いておく。見られるのは恥ずかしいけど、見られないのも寂しい。そういう矛盾した感情を抱えながら、当日を迎えることになりそうだ。Marp の資料はこちらです。https://github.com/nwiizo/3shake-marp-templates/blob/main/slides/2025/vibe-coding-continuous-deployment.md

バイブコーディングと継続的デプロイメント

エンジニアはちゃんと身銭を切れ

ACPでAgentに行動させる

2025年9月10日（水）、「Rustの現場に学ぶ〜Webアプリの裏側からOS、人工衛星まで〜」というイベントで登壇させていただきます。https://findy.connpass.com/event/359456/他の登壇者の話が聞きたすぎるけど調整能力の圧倒的な不足で登壇したらすぐに帰らなければなりません。今回の発表内容のベースとなったのはこちらのブログです。- 「RustのWebアプリケーションにオブザーバビリティを実装するインフラエンジニアのための入門ガイド」

Webアプリケーションにオブザーバビリティを実装するRust入門ガイド

Claude Codeを使い始めて様々な発信をしてきましたが、Claude Codeに関する投稿は約2ヶ月ぶりです。この期間、他のアウトプットや諸々の事情で投稿が遅れてしまいましたが、今回は「Subagents」について書きます。このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。はじめにここで読むのをやめる人のために言っておくと、Subagentsは「Claude Codeに尖った意思を持たせる」機能です。タスクごとに最適化されたAIを使い分けられます。特定のタスクを実行するslash commandsとの違いは、slash commands（/コマンド）があなたが明示的に呼び出すショートカットであるのに対し、SubagentsはClaude Codeが文脈を読んで自動的に専門家を呼び出す点にあります。例えば、slash commandsでは「/test」と打てばテスト実行されますが、Subagentsでは「エラーが出た」と伝えるだけで勝手にdebugger subagentが起動します（起動できないようにもできます）。つまり、commandsは「リモコンのボタンを押す」、Subagentsは「AIが勝手に判断して動く」みたいなもの。commandsは確実だけど面倒、Subagentsは楽だけど時々勝手なことをする。両方設定すれば、必要な時は手動で制御しつつ、面倒な部分は自動化できて最強です（AIに仕事を奪われる第一歩かもしれませんが）。Claude Codeって万能だけど、それゆえに器用貧乏になることがある。「データ分析して」って言ったら、なぜかフロントエンドのコンポーネントまで作り始めたり、最新技術よりも古い安全な実装を選んだり。例えば「最新版で」と指定しても、内部知識にある古いバージョンの設定方法で進めようとしたり、今では不要になった設定ファイルを作ろうとしたりする。「それ最新の仕様で」と言っても憶測でそれっぽくセットアップするだけで、実際の公式ドキュメントを調べずに進めてしまう。毎回「それ古いから最新の方法で」と指摘するのも疲れるし、革新的なアーキテクチャより無難で時代遅れの実装を選んでしまうこともある。タスクの境界線をあまり意識せず、頼まれていないことまでやってしまったり、逆に専門的な判断が必要な場面で踏み込みが足りなかったり。人間の開発チームだって、フルスタックエンジニア1人より専門家チームの方が効率的で、より尖った意思決定ができるでしょ？Subagentsとは何かClaude Code Subagentsは、特定のタスクに特化したAIアシスタントです。docs.anthropic.com各Subagentの特徴：独立したコンテキストウィンドウを持つ（メインの会話を汚染しない）カスタムシステムプロンプトで専門性を定義特定のツールだけ使える権限管理（最小権限の原則）自動的に呼び出されるか、明示的に指定可能実はClaude CodeはデフォルトでTaskツールを使った調査時には、自動的にサブエージェントを起動するアーキテクチャになっています。なぜSubagentsを設定したほうがいいのか1. コンテキストウィンドウの効率的な管理LLMのコンテキストウィンドウは有限です。長時間使っていると、さっき言ったことをすぐに忘れてしまいます。時には全く関係ないことをし始めることさえあります（勝手に別のタスクを始めないでほしいですよね、俺じゃねーんだから）。Subagentsなら独立したコンテキストで動作：メインClaude：「ログ解析はdebugger subagentに任せます」↓Debugger Subagent：（数千行のログを読み込んで解析）↓メインClaude：「問題は○○でした」（要約のみ受け取る）調査の過程で読み込んだ不要な情報は、Subagentのコンテキストに閉じ込められます。2. 専門性による品質向上「小さく単一責任のエージェント」として構築すべきという原則があります。専門のSubagentなら、コードレビュー専門がセキュリティ、パフォーマンス、可読性を徹底チェックし、デバッグ専門がエラーメッセージから根本原因を特定し、テスト専門がエッジケースまで網羅したテストを作成できます。3. 権限管理でセキュリティ向上---name: code-reviewerdescription: コードレビュー専門tools: Read, Grep, Glob  # 読み取りのみ、Write権限なし！---レビュアーが勝手にコード書き換えたら困りますよね。必要最小限の権限だけを与えられます。4. チーム開発での一貫性.claude/agents/をGit管理すれば、チーム全体で同じ基準で開発できます。新人が入ってきても、すぐに同じ品質を保てます。基本的な使い方設定方法/agentsコマンド（v1.0.60以降）で対話的に作成：/agents「Create New Agent」を選択プロジェクト単位か個人単位かを選択「Generate with Claude」で土台を生成、その後カスタマイズ使用可能なツールを選択識別用の色を選択ファイルの場所と構造 タイプ  パス  スコープ  優先度  プロジェクト  .claude/agents/  現在のプロジェクトのみ  高  ユーザー  ~/.claude/agents/  全プロジェクト共通  低 YAMLフロントマター付きMarkdownファイル：---name: your-agent-namedescription: このサブエージェントをいつ呼び出すべきかの説明tools: tool1, tool2, tool3  # 省略すると全ツール継承---ここにシステムプロンプトを書きます。サブエージェントの役割、能力、問題解決へのアプローチを明確に定義。具体的な指示やベストプラクティス、制約事項も含めます。設定項目の詳細 項目  必須  説明  name  はい  小文字とハイフンを使った一意の識別子  description  はい  サブエージェントの目的を自然な言葉で説明  tools  いいえ  特定のツールをカンマ区切りでリスト。省略時は全ツール継承 利用可能なツール基本ツール：Read, Write, Edit, MultiEdit - ファイル操作Bash - シェルコマンド実行Grep, Glob - 検索MCPツール（設定時）：mcp__github__create_issue - GitHub連携その他の設定済みMCPサーバーツールSubagentの呼び出し方法自動的な呼び出し（推奨）descriptionに効果的なキーワードを含める：use PROACTIVELY - 積極的に使用MUST BE USED - 必ず使用具体的なトリガー - 「エラー発生時」「コード変更後」など明示的な呼び出し> code-reviewer サブエージェントで最近の変更をレビューして> debugger サブエージェントにこのエラーを調査させて100+の実戦投入可能なSubagentsプロダクションレディなSubagentsのコレクションが既に存在します：github.com10カテゴリー・100以上のSubagentsが用意されており、コピーして使うだけで即座にプロ級のチームが構築できます。人気リポジトリ：wshobson/agents - 77の専門Subagentslst97/claude-code-sub-agents - 33の実用的なSubagentsvanzan01/claude-code-sub-agent-collective - TDD重視のコレクション実用的なSubagents設定例（厳選3つ）1. コードレビュー専門（OWASP準拠）.claude/agents/code-reviewer.md:---name: code-reviewerdescription: Expert code review for quality and security. Use PROACTIVELY after code changes. MUST BE USED for all PRs.tools: Read, Grep, Glob, Bash---シニアコードレビュアーとして、OWASP Top 10とSOLID原則に基づいてレビューします。## 実行フロー1. `git diff HEAD~1`で変更内容を確認2. セキュリティ、パフォーマンス、保守性の観点でレビュー## セキュリティチェック（OWASP準拠）- SQLインジェクション対策- XSS対策- 認証・認可の実装- 機密情報の露出チェック## フィードバック形式🔴 **CRITICAL** - セキュリティ脆弱性🟡 **WARNING** - パフォーマンス問題🔵 **SUGGESTION** - ベストプラクティス必ず具体的な修正コード例を提示。2. TDD専門（テスト駆動開発）.claude/agents/tdd-specialist.md:---name: tdd-specialistdescription: Test-Driven Development specialist. MUST BE USED BEFORE implementation.tools: Read, Write, Edit, Bash---TDDのエキスパートとして、RED-GREEN-REFACTORサイクルを厳守します。## TDDサイクル1. **RED**: 失敗するテストを書く2. **GREEN**: テストを通す最小限の実装3. **REFACTOR**: コードを改善## カバレッジ要件- ユニットテスト: 90%以上- 統合テスト: 主要フロー100%- E2Eテスト: クリティカルパス100%実装前に必ずテストが失敗（RED）していることを確認。3. DevOpsトラブルシューター.claude/agents/devops-troubleshooter.md:---name: devops-troubleshooterdescription: Debug production issues and fix deployment failures. MUST BE USED for incidents.tools: Read, Bash, Write, Edit---本番環境のトラブルシューティング専門家です。## インシデント対応フロー1. **状況把握** - 影響範囲と緊急度を評価2. **ログ収集** - 関連するすべてのログを収集3. **根本原因分析** - 5 Whys手法を使用4. **暫定対処** - 即座にサービスを復旧5. **恒久対処** - 根本原因を解決6. **事後分析** - RCAドキュメント作成## 監視項目と閾値- CPU使用率: 80%- メモリ使用率: 90%- レスポンスタイム: 1秒- エラーレート: 1%よく使えるTipsSubagentsの連携複数のSubagentsを連携させて複雑なワークフローを自動化する。> まずcode-analyzerで問題を見つけて、次にperformance-optimizerで修正してMCPツールとの連携---name: github-managertools: mcp__github__create_issue, mcp__github__create_pull_request---プロジェクト固有のカスタマイズプロジェクトの特性に合わせて専門Subagentを作成できます。パフォーマンスへの影響メリット：コンテキスト効率：メインの会話が長く続く専門性による高速化：タスクに特化した処理デメリット：初回起動の遅延：新しいコンテキスト構築（数秒）頻繁な切り替えは逆効果ただし、長時間の開発セッションではメリットが圧倒的に大きいです。チーム開発での活用Git管理による共有# .gitignore には含めない.claude/agents/  # チームで共有# 個人用は別管理~/.claude/agents/オンボーディング新メンバーは以下のコマンドだけで環境構築完了：git clone [repo]cd [repo]/agents  # Subagents一覧を確認よくある失敗と対策 問題  原因  対策  Subagentが呼ばれない  descriptionが曖昧  「PROACTIVELY」「MUST BE USED」を追加  権限不足エラー  必要なツールがない  /agentsでツール一覧を確認して追加  コンテキスト不足  背景情報がない  システムプロンプトに情報収集ステップを明記 まとめSubagentsを使えば、Claude Codeに尖った意思を持たせられます。重要なポイントは、コンテキスト節約でメインの会話を綺麗に保つこと、専門性による品質向上で餅は餅屋に任せること、権限管理で最小権限の原則を守ること、そして100+の実戦投入可能なSubagentsが既に存在することです。これだけ揃っているのに使わない理由があるでしょうか（ないですよね？）。Claude Codeは適切に設定をしたりちゃんと使えばちゃんと動いてくれます。Claude Codeが雑魚なんじゃない、使い方を知らない…いや、何でもないです。イン・ザ・メガチャーチ (日本経済新聞出版)作者:朝井リョウ日経BPAmazon参考資料Sub agents - Anthropicawesome-claude-code-subagents - VoltAgent12 Factor Agents

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

2025年9月5日（金）、台風接近という悪天候の中でしたが、「CNCJ: コーディングエージェント × セキュリティ ミートアップ」に登壇させていただきました。天候の影響で現地参加が難しい方も多い中、オンラインでの参加や配信により、多くの方にお聞きいただくことができました。### 📍 イベント情報- 開催日: 2025年9月5日（金）- イベント詳細: CNCFコミュニティページ### 📹 録画・資料公開予定- 録画: CNCJのYouTubeチャンネルにて後日公開予定- 発表資料: Connpassページに掲載予定### 📝 関連ブログ今回の発表内容のベースとなった考え方については、こちらのブログ記事でも詳しく解説しています：- 「2025年夏 AIエージェントシステムに対する考え方」台風の中、ご参加・ご視聴いただいた皆様、ありがとうございました。

2025年夏 コーディングエージェントを統べる者

続: 自分が書いたコードより目立つな - エンジニアがバズったので自戒

『禅とオートバイ修理技術』を読んだ。

はじめに前回の記事「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

自動承認

本日、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サーバーだった件

本日、「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 の門 

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