はじめに この記事では、 AIコーディングエージェント向けのタスク管理ツール「Beads (bd)」を紹介します。 Claude Codeなどのエージェントにタスクを記憶させ、セッションをまたいだ作業管理を可能にするツールです。 beadsとは AIエージェントが使用することを前提に作られたタスク管理ツールです。 bdコマンドというCLIを使ってタスク管理ができます。 CLIでタスクを操作できることから、Claude Codeなどのバイブコーティングツールを使用する開発者から高評価を得ています。 GitHub - gastownhall/beads: Beads - A memory upgrade for your coding agent GitHub Issueなどとの違い プロジェクトのタスク管理というとGitHub Issueが古くから使われていますが、GitHub Issueとbeadsのメカニズムの違いや、beadsを使うメリットは以下の通りです。 依存関係の設定ができる このタスクを完了しないと次のタスクを実行できない、といった複雑な依存関係の設定が可能です。 DBとJSONLでタスク管理 DBファイルとjsonlファイルの2つを用いてタスクを管理します。 DBファイル上でタスクのステータス、優先度、説明などが記録されています。 軽量な内部DBにクエリを実行することで、エージェントは必要な情報のみを参照でき、コンテキストの肥大化を防げます。 DBへの変更はjsonlファイルにも同期され、人間にも読みやすい形式で表示されるため、Gitなどのバージョン管理ソフトで差分を確認できます。 ローカルのDBファイルを用いるので、クラウドを使わずオフラインでも動作します。 コマンドラインから操作できるので、AIエージェントからも操作が可能です。 エージェントにセッションをまたいだ情報を記憶させるrememberコマンドなど、エージェント向けの機能があります。 初回セットアップ # Windowsにbeadsをインストール irm https://raw.githubusercontent.com/gastownhall/beads/main/install.ps1 | iex ## 環境変数 Pathに以下のPathを設定 >> ==> bd installed to C:\Users\pocke\AppData\Local\Programs\bd\bd.

はじめに 会社員からフリーランスエンジニアとして独立すると、多くの方が驚くのが健康保険料の負担です。 会社員時代は給与から天引きされ、金額をあまり意識していなかった方でも、独立後に自分で保険料を計算・納付する立場になると、想像以上の金額に驚くケースが少なくありません。 特にフリーランスエンジニアは、案件の単価が比較的高く、所得が上がりやすい職種のため、国民健康保険料も高額になりがちです。 この記事では、フリーランスエンジニアが検討すべき健康保険の主な選択肢を整理し、それぞれのメリット・デメリット、保険料の考え方について解説します。 最終的な選択や保険料の具体的な試算については、お住まいの自治体窓口や社会保険労務士、税理士に確認することをおすすめします。 フリーランスエンジニアが健康保険で直面する課題 国民健康保険料が高くなる理由 会社員が加入する協会けんぽ等の健康保険は、保険料を会社と折半するため、個人の負担は所得の一定割合に抑えられています。 一方、独立後に多くの方が加入する**国民健康保険（国保）**は、原則として以下の要素で保険料が計算されます。 所得割: 前年の所得に応じて金額が上がる部分 均等割: 世帯の加入者数に応じてかかる定額部分 平等割: 世帯ごとにかかる定額部分（自治体によって有無が異なる） このうち所得割は、所得が増えるほど比例して保険料が上がっていく仕組みのため、独立して所得が伸びたフリーランスエンジニアほど、国保料の負担も重くなりやすいという特徴があります。 なお、国民健康保険には保険料の**上限額（賦課限度額）**が設定されており、青天井に上がり続けるわけではありません。ただし、上限額自体も年々見直されており、高所得層にとっては依然として大きな負担になりやすい制度です。 会社員時代との違い 会社員の健康保険と異なり、国民健康保険には以下のような特徴もあります。 保険料の労使折半がなく、全額自己負担 傷病手当金・出産手当金が原則として支給されない（自治体や制度改正状況によって例外あり） 前年所得をもとに保険料が決まるため、独立初年度は前職の給与所得がベースになることがある こうした違いを理解した上で、自分に合った健康保険の選択肢を検討することが重要です。 主な選択肢の比較 フリーランスエンジニアが検討できる健康保険の選択肢は、大きく**国民健康保険（国保）と社会保険（社保）**の2系統に分かれます。 さらに国保は「市区町村国保」と「国民健康保険組合」の2種類、社会保険は法人の役員・従業員になることで加入するため、フリーランスが社会保険につながるルートとして「任意継続」「マイクロ法人」「社保加入代行」の3通りがあります。 健康保険 国民健康保険団体（国保） 市区町村国保 国民健康保険組合（同業者組合） 社会保険団体 (社保) 全国健康保険協会（協会けんぽ） 健康保険組合 (組合健保) 共済組合 社会保険加入方法 任意継続被保険者制度 マイクロ法人スキーム 社保加入代行・一般社団法人加入 国民健康保険（国保） 市区町村国保 最も一般的な選択肢で、独立後に手続きをしなければ自動的にこの制度の対象になります。 市町村ごと微妙に保険料が異なるため、保険料が安い市町村で開業することで微小ですが保険料を抑えることができます。` メリット 手続きが比較的シンプルで、市区町村の窓口で完結する デメリット

はじめに Azure SRE Agent では、ユーザーが特定のタスクを実行するための特化したエージェントを、カスタムエージェントとして定義・作成することができます。 本記事では、カスタムエージェントの定義方法から実際の活用方法まで、詳しく解説します。 カスタムエージェントとは カスタムエージェントは、ユーザーが入力した特定のタスクを実行するために特化したエージェントです。 標準的なSREエージェントではカバーしきれない、特殊な役割や機能を必要とする場合に活用します。 カスタムエージェントの定義方法 カスタムエージェントは以下のようにYAML形式で定義できます。 name: database_expert system_prompt: |You are a database specialist. Analyze query performance, diagnose connection issues, and recommend optimizations. handoff_description: Handles SQL and database troubleshooting tools: - execute_kusto_query - azure_cli connectors: - azure_sql enable_skills: true # Can use skills for additional expertise 定義要素の説明 要素 説明 name カスタムエージェントの識別子 system_prompt カスタムエージェントの役割や動作を定義するプロンプト handoff_description オーケストレーターがこのカスタムエージェントにタスクを委任する判断基準となる説明文 tools カスタムエージェントが使用できるツール（azコマンド、外部APIなど） connectors 接続するAzure リソースやサービス enable_skills 有効にするとカスタムエージェントがスキルに動的にアクセス可能 重要な注意点 SRE エージェントのカスタムエージェントは、Claude Code のサブエージェントとは異なり、使用するモデルを指定することができません。

はじめに Azure SRE Agentは、Azure Monitorやログなどの監視データを活用してインシデント対応を支援するAIエージェントです。 その能力を最大限に引き出す鍵となるのが「コネクタ」機能です。 コネクタを設定することで、SREエージェントはAzure Monitor、Application Insights、Log Analyticsといった監視サービスや、GitHubリポジトリ、Teamsなどの外部サービスとシームレスに連携できるようになります。 本記事では、Azure SRE Agentのコネクタの概要、サポートされているサービス、導入するメリット、そしてApplication InsightsとLog Analyticsの違いについて解説します。 Azure SRE エージェントのコネクタ エージェントには、Azureサービスへの組み込みアクセスが用意されています。 コネクタは、外部サービスとSREエージェントを接続し、SREエージェントから外部サービスへのクエリの実行や、コードの読み取り、通知の送信を可能にします。 Azure公式ドキュメント: SREエージェントのコネクター サポートされているコネクタ Azure Monitor Application Insights Log Analytics Azure Resource Graph GitHubリポジトリ Teams カスタムAPI コネクタのメリット コネクタが設定されていない場合でも、SREエージェントは az コマンドが組み込まれているので、azコマンドを使ってApplication Insights、Log Analyticsなどへのクエリの検索は可能です。 敢えてコネクタを設定するメリットとしては、以下の点があります。 コネクタを使用するメリット： 毎回対象を指定しなくてもよい - 特定のLog AnalyticsワークスペースやApplication Insightsリソースをエージェントが継続的に認識 接続先のデータがコンテキストに入る - 接続先の監視データが前提知識として扱われやすくなり、調査時の文脈理解が速くなる 高度な診断がしやすくなる - 接続されたリソース全体をまたいだMCPベースの診断に使え、組み込みで提供されたToolsが使える コネクタは「単にクエリできるようにする」ためだけでなく、「どの監視データを常に見てよいかをエージェントに覚えさせ、継続的な診断能力を上げる」させることができます。 Application InsightsとLog Analyticsの違い Application Insightsで表示できるメトリクスはLog Analytics Workspacesに保存されます。 Log Analyticsだけでなく、Application Insightsを使うメリットとしてはLAWの情報を抽象化（アプリケーションマップなど機能）が使えるようになることです。

はじめに Azure SRE Agent には、過去のインシデント対応やユーザーとのやり取りから学習した知識を蓄積し、次回以降の対応に活かす「メモリ」という仕組みがあります。 本記事では、メモリの種類や自動学習の仕組み、ユーザーメモリの操作方法、ナレッジベースとの違いについて解説します。 メモリ メモリとは過去のインシデントで何が機能していたかなど、エージェントに蓄積することができる知識情報です。 メモリの種類 情報源 発見内容 最適な用途 過去のインシデント 同様の問題を解決した手順 以前、どのようにこれを修正したのですか。 ユーザーメモリ 明示的に保存するファクト “私の環境設定が使用することを覚えておいてください…” ナレッジベース アップロードしたランブックとドキュメント “標準手順に従う” 自動学習 SREエージェントはユーザーとの会話から自動で学習し、メモリに記録します。 スレッドが更新されなくなってから30分後、エージェントは会話を評価し、学習のインデックスを作成します。 プロアクティブな知識の永続化 完了したスレッドから学習するだけでなく、エージェントは会話中に重要と判断した知識をナレッジファイルに保存します。 ナレッジファイルは memories/synthesizedKnowledge/ 配下に保存され、次回セッション開始時に自動読み込み、より賢い回答を生成します。 ナレッジファイルの種類 ファイル 内容 文字数上限 overview.md サービスの概要とインデックス 約2,000文字（常にコンテキストに読み込まれる） トピックファイル 特定の主題に関する詳細な注意事項（例: aks-networking-gotchas.md） 各1,000文字 team.md チームメンバー、役割、専門知識 最大500文字 architecture.

はじめに 2026年6月2日〜3日に開催された Microsoft Build 2026 で、AIエージェント開発プラットフォームの Microsoft Foundry が大きく前進しました。 本記事では、機能の仕様を羅列するのではなく、「ぶっちゃけ何ができるのか」「自分たちにどう嬉しいのか」 を中心に、実務エンジニア向けにかみ砕いて解説します。 Microsoft Build 2026 公式サイト Foundryって、ざっくり何？ 一言で言うと、。 「AIエージェントを、作って・動かして・賢くし続けるための、全部入りプラットフォーム」 「エージェントを作って・動かして・賢くし続ける」ための機能が一通り揃い、本格的な本番利用に耐えるプラットフォームになりました。 従来のつらみ（Before） 社内用のAIアシスタントを1つ作りたい、となったら、どうなるか。 エージェントのロジックを書く（これが本来の本題） ↓ でもその前にやることが山積み…… □ 社内文書を検索する仕組み（RAG）を自作 □ Outlook、Teams、Jiraなどと連携するコード □ ユーザー認証と権限制御 □ セキュアに動かすサーバー基盤 □ ログ、監視、コスト管理 □ 「前回の会話を覚える」機能 ↓ やっと本題……でも予算も時間も尽きた 😫 一番大事な「エージェントを賢くする」ことに集中できない のが、従来の最大の問題でした。 Foundryだと（After） Foundryを使うと、こうなります。 エージェントのロジックを書く（ここに集中できる） ↓ 回りは全部Foundryにお任せ ✅ 社内文書検索 → Foundry IQ ✅ ツール連携 → Toolboxes ✅ 認証・権限 → 自動で処理 ✅ 本番サーバー → Hosted Agents ✅ 監視・コスト管理 → 自動で取得 ✅ 会話を覚える → Memory 「エージェントがどう答えるか」という中身だけ書けば、回りのインフラ仕事はFoundryが全部面倒を見てくれる。

はじめに 少ない操作でパソコン上のファイルやアプリを素早く起動できるソフトウェアをランチャーソフトと言います。 ランチャーソフトの代表例として、「WinLancher」、「CLaunch」、「Orchis」、「PaperPlane Smart Launch」、「Aqulina」などがあります。 本記事では、海外で人気のランチャーソフト「Flow Lancher」について紹介します。 Flow Launcherは日経XTechでも取り上げられており、日本国内でも利用されている方も増えているので、おすすめです。 Flow Lanucherとは Flow Launcherは無料で使えるオープンソースのランチャーソフトです。 Flow Launcher 公式HP Flow Launcher Gitリポジトリ ランチャーソフトには、Claunchなどランチャーから起動させるアプリやファイルを事前登録するタイプのものと、検索ウィンドウから指定したキーワードに一致するアプリやファイルを開くタイプの2タイプがあります。 Flow Lanucherは後者の検索で検索ウィンドウを使うタイプで、アプリ、ファイルを高速起動できます。 Flow Launcherの特徴 PC内のアプリ、ファイルの起動以外にも様々な機能を持つ プラグインにより機能拡張が可能 アプリ、ファイル起動以外の様々な機能 PC内のアプリ、ファイルの起動だけでなく、WEB検索、電卓計算、プロセスの終了などのコマンドの実行が可能です。 デフォルトだと、以下のような機能が組み込みでインストールされています。 名前 説明 Browser Bookmarks bというキーワードを入力するとWEBブラウザのブックマークから検索できる Calculator 10*2+1のような計算式を入力すると、電卓を使って検索できる Process Killer killというキーワードを入力すると指定したプロセスを停止できる Windows Settings sというキーワードを入力すると、Windowsの設定から検索する shell >というキーワードを入力すると、Commandpromptまｈた、Powershellからコマンドを実行できます。 pingなどの疎通確認で利用できます。 Web Search WEBブラウザを起動し、WEB検索を行うことができる。先頭に入力したキーワードに応じて動作の変更可能 ※例として以下のモードがあります。 - twitter : Twitterから検索 - translate : Google翻訳から検索 - github : Githubから検索 - gmail : Gmailから検索 - drive : Google Driveから検索 - stackoverflow : StackOverflowから検索 - youtube : youtubeから検索 System Command FlowLancher組み込みコマンドを入力して、実行できます。例として以下のものがあります。 - Shutdown : OSをシャットダウン - Restart : OSを再起動 - Log Off : ログオフ - Sleep : スリープ - Empty Recycle Bin : ゴミ箱を空にする - Settings : Flow Lancherの設定を開く WEB検索 検索に指定したウィンドウから、Googleの検索エンジンを使ってWEB検索を行うことができます。

はじめに Azure SRE Agent は、Azure 環境における運用業務を効率化・自動化するために登場した AI エージェントです。 従来の監視ツールやオペレーション自動化ツールとは異なり、インシデントの検知だけでなく、その原因調査や対応支援、さらにはリソース操作までを一貫して実行できる点が大きな特徴です。 本記事では、Azure SRE Agent の基本機能や料金体系、活用方法について整理し、実運用でどのように活かせるのかを解説します。 Azure SRE Agentとは Azure SRE Agent は、Azure 上のリソースに対して継続的なヘルスチェック、インシデント調査、復旧支援を行うことができるAI エージェント。 様々な種類のトリガーで起動できる (チャットベース、Webhook通知、cronによる定期実行) azコマンドを内部で実行できるのでAzure上のリソースに対する操作が可能 ハーネス機能が実装されている (Skills, サブエージェント作成、 MCP連携) メリット 多様なトリガーに対応 チャットベース Webhook通知 cronによる定期実行 Azure操作が可能 内部で az コマンドを実行できるため、Azureリソースの直接操作が可能 拡張性（ハーネス機能） Skills サブエージェント作成 MCP連携 公式情報 Microsoft公式ドキュメント Microsoft公式YouTube GitHub SREエージェント Microsoft公式ドキュメント: Azure Advisor Optimization workbook 料金体系 料金は Azure Agent Units（AAU） を基準に算出されます。

はじめに Claude Codeには、開発作業を効率化するための拡張機能としてSkills、Custom Subagents、Dynamic Workflowsの3つの仕組みが用意されています。 これらはどれも「Claude Codeにできることを増やす」という目的は共通していますが、それぞれ特徴や向いている用途が異なります。 本記事では、それぞれの仕組みの概要と使い方、そして3つの違いを整理し、どのような場面でどれを使うべきかの判断材料をまとめます。 Skillsとは SkillsはClaude Codeに特定のタスクを実行するための手順や、知識をパッケージとして一つにまとめて登録し、Claude Codeから実行できるように仕組みです。 Anthropic公式: ClaudeにSkillsを拡張する ユースケース Anthropicのブログではスキルのユースケースとして以下の9種類のスキルが代表例として紹介されています。 Anthropic公式ブログ: Skillsの用途 # 用途 概要 代表例 1 ライブラリ・API参照 内製ライブラリ・SDKの正しい使い方を知識としてClaudeに教える billing-lib, sandbox-proxy 2 プロダクトバリデーション ヘッドレスブラウザ等でUI操作を自動検証し、各ステップの結果をチェック signup-flow-driver, checkout-verifier 3 データ取得・解析 DWHや監視ツールと連携し、認証付きでデータを取得・分析 funnel-query, grafana 4 ビジネスプロセス自動化 進捗報告報告やチケット作成など定型作業をワンコマンド化 standup-post, weekly-recap 5 スキャフォールディング 組織仕様に合わせたコードの雛形・テンプレートを生成 new-migration, create-app 6 コード品質・レビュー 組織スタイルの強制や adversarial review で品質を維持 adversarial-review, code-style 7 CI/CD・デプロイ PR監視、自動リトライ、ロールバック付きデプロイを自動化 babysit-pr, deploy-<service> 8 ランブック アラートから障害調査・ログ相関・構造化レポートを自動作成 oncall-runner, log-correlator 9 インフラ運用 定期メンテナンスや危険操作をガードレール付きで実行 <resource>-orphans, cost-investigation 1.

はじめに 「社会人になれば、知識も精神も自立した大人になる」──こう期待されているのが常識です。 学生時代の未熟さを脱し、社会経験を積んで一人前の人間に成長する。 そんなイメージが一般的でしょう。 しかし、現実はどうでしょうか。 筆者がエンジニアとして働く中で出会った多くの社会人は、知識も精神も未成熟なままであることの方が多いのです。 「社会人は自立した大人」という通説は、実は間違っているのかもしれません。 本記事では、現場で目の当たりにしてきた衝撃的な実例を通じて、社会人の未熟さについて痛烈に指摘したいと思います。 そして何より、これから社会に出る若い方に伝えたいことがあります。先輩や上司がみな頼りになる大人だとは限りません。立場が上だからといって、いつも正しいとは限らないのです。本記事が、周りの人を鵜呑みにせず、自分のキャリアを自分で考えるきっかけになれば嬉しいです。 無知な人が多い 製品名の「TM」が理解できない これはあるシステムの社内向けのスライド資料についてレビューで起きた話です。 企業の上司が、製品名に「TM」がついていないと指摘をしてきました。 TMは「Trade Mark」の略で、商標登録を示す記号です。 TMはロゴや商品名が商標登録されていることを外部に示すものなので、ロゴを引用している訳でもない社内向けの資料に記載する必要はありません。 悪意はないのだと思いますが、上記のような常識が欠落している方は多く、レビューでもピンとがづれた指摘を受けるケースは残念ながら多々あります。 正解を教えても学ばない これはDevOpsの導入支援を行っていたプロジェクトでの会話の話です。 上司:「運用者って英語でなんて言うの？」 部下: 「operatorです。」 上司: 「なんか違うなー、Actorにしよう!!」 DevOpsを扱う企業でさえ、基本用語の理解がこんなにもおろそかになっているのです。専門用語を正確に理解せずに専門的な仕事をしている──これが現場の現実です。 また、正解を提示しても、同じ間違いを繰り返す。あるいは、正しい表現を使うように伝えても、自分の好きな間違った単語を使い続ける。 学ぶ姿勢がないのです。教えられることへの感謝も、知識を自分のものにしようとする意欲もない。 無知であること自体は問題ではありません。誰でも最初は無知です。問題なのは、無知を自認せず、学ぼうとしないことです。 エンジニアは金に疎い SNSでのビジネスロマンス詐欺被害 これはあるエンジニアがSNSを通じて知り合った外国企業に金を騙し取られた話です。 「取引相手」と思っていた相手は、実は詐欺グループでした。 「投資してみない？ 儲かるよ」 そう言われて、最初は数千円。その後、何度か追加投資を促され、最終的には50万円を失ったそうです。 驚くべきは、その後の彼の態度です。 「まあ、勉強代だと思えば」 そうケロッと言うのです。50万円という大金を失ったにもかかわらず、怒ることも悔やむこともなく、「勉強代」という言葉で片付けているのです。 この軽さ──これが金銭感覚の欠落した社会人の典型です。 借金を自慢するピエロエンジニア これはある40代のエンジニアの方の友人との金銭トラブルの話です。 ご本人はコミュニティを作っていると称して、カフェ会などを開いているそうです。 その方のお話を伺ったのですが、 ピエロエンジニアさん:「友人が困っているから20万円貸したけど返ってこなかったことあるよ(キリッ)」 エンジニアA: 「えっ、20万円も！？」 ピエロエンジニア: 「自己投資(人生経験)だったと思ってるよ(ドヤ～)」 大金を人に貸すのはよくない、お金を返さないような人は友人ではない、小学生でも分かることですよね。 騙されているにもかかわらず、それを「自己投資」だと言い張る。 しかも、その状況を自慢話のように語るのです。 ご自身はコミュニティと称してやっていることもハッカソンやアイデアソンなどではなく、 小規模なカフェ会やボードゲーム会で学生さんでもできるような大したことではなく、年齢に相応しい行動とは思えないですが、主催して人を集めている自分に酔っているようです。 ちなみに該当のエンジニアは、こちらのだそうです。 個人的に、近づかないことを推奨します。 青色申告の重要性を知らない これは副業やフリーランスで働くエンジニアの確定申告の話です。 「白色申告でいいよ、簡単だから」 そう言って、経費がまったく計上できない白色申告を選ぶエンジニアがいます。家賃、通信費、書籍代、機材代──本来経費として計上できるものが、何も計上されていないのです。 青色申告と白色申告の違い、経費の計上方法、節税の基本。これらを知らないだけで、数十万円単位で損をしているのです。 エンジニアは変な人が多い 簡易ハッカソンの奇行 これはある簡易ハッカソンで参加したエンジニアが開発したアプリの話です。