はじめに 目標管理制度を初めて導入する会社では、思わぬところでつまずくことがあります。 今回は、目標設定そのものに膨大な時間がかかってしまい、肝心の業務改善に手が回らなくなってしまった職場のトラブルを紹介します。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 「目標設定に四半期の約1/4を消費する会社」 これは設立30年以上の中小SIerでの出来事。 これまで目標管理の仕組みが存在しなかったこの会社で、経営層の意気込みのもと、初めて全社員による個人目標設定が導入されることになった。 現場を統括する課長Hが自身のチームの目標を作成し、役員Fへの説明の場に持ち込んだ。 課長H 🙂 「今期のチーム目標は『担当システムの保守品質を向上させる』としました。」 役員F 😐 「そんな目標じゃ、ぬるい。もっと危機感を持って考えろ。」 課長H 😳 「危機感……ですか。具体的にはどのあたりを……」 役員F 😠 「そんなことまで俺が説明しなきゃいけないのか！お前がチームの責任者だろう！！」 課長Hは何が悪かったのか具体的な説明を得られないまま、感情論だけで目標を突き返された。 しかし部下への説明の場では、役員から言われたことを何とか自分の言葉に変換しようとする。 課長H 😓 （役員は「危機感」とか「ぬるい」って言ってたな……つまり、もっと厳しくすればいいのか？） 課長H 🙂 「みんな、今期の目標だけど、もっと危機感を持って厳しめに設定しよう。」 部下G 🤔 「危機感、というのは具体的にどういう……」 課長H 😅 「いや、そこはお前らで考えてくれ。とにかく緩い目標はダメだって話だから。」 部下Gたちは意図のつかめないまま、とりあえず数値を厳しくした目標を作り直し、再び課長Hを経由して役員Fへ持ち込む。 課長H 🙂 「危機感を持たせた目標に修正しました。」 役員F 😡 「なんだこれ、数字だけ厳しくすればいいってもんじゃないだろ！！本質を考えろと言ったはずだ！！」 課長H 😨 「す、すみません……」 課長Hはまた役員から罵声を浴びるが、「本質」という言葉の意味も具体的にはつかめないまま部下の元へ戻る。 課長H 😰 「役員から、本質を考えろって言われたんだ。もう一度、本質的に考え直してくれ。」 部下G 😔 「本質……というのは、前回の『危機感』とは違う話ですか？」 課長H 😩 「いや……それは……とにかく、もっと深く考えてくれ。」 部下Gたちは、前回の指摘との関係もわからないまま、また目標を修正する。

はじめに 物事には地域ごとの向き不向きがある、というのはよく言われる話です。 例えば「立ち食いそば」は東京や大阪では駅前の当たり前の光景ですが、地方に行くとほとんど見かけなくなります。 これは単純な人口密度の差だけでなく、都市部特有のせっかちな気質や、通勤・移動の合間に短時間で済ませたいという生活スタイルが背景にあると言われています。 「少しでも早く」「立ったままでも構わない」という都市部の価値観があってはじめて成立する業態であり、時間にゆとりのある地方では同じ理屈が働きにくいわけです。 需要密度やビジネスの成立条件だけでなく、その土地の生活スタイルや文化と合っているかどうかが大きく関係していると言われています。 サッカーの世界でも同様の話があります。 中国は巨額のチャイナマネーを投じて自国リーグの強化を図りましたが、結果として世界トップレベルへの成長には至っていません。 理由の一つとして挙げられるのが、他人を信頼しない・組織のために動く協調性が根付いていないといった国民性が、パスをつないで連携するヨーロッパ型のサッカースタイルと相性が悪かった、という指摘です。 お金をいくら投じても、その土地の文化や気質と合わなければ、望んだ方向には育たないという典型例と言えるかもしれません。 これはシステム開発という仕事にも、同じことが言えるのではないかと思っています。 岡山で長年システム開発に携わっていると、「この土地はシステム開発とあまり相性が良くないのでは」と感じる場面がたびたびあります。 感覚論だけで語ると単なる愚痴になってしまうので、この記事ではできるだけ具体的な事実やデータを示しながら、岡山県とシステム開発の相性について考察してみます。 結論を急ぐ記事ではありません。最後まで読んでいただいたうえで、読者自身がどう感じるかを考えていただければと思います。 1. 図書館のIT関連キュレーションの弱さ 岡山県立図書館は、蔵書数・貸出数ともに全国トップクラスの実績を誇る図書館です。 実際に「都道府県立図書館 貸出冊数」で検索すると、岡山県立図書館は毎年上位にランクインしています。 一方で、IT関連書籍、特にAWS関連の技術書に絞って蔵書を確認すると、2026年時点で該当する蔵書は0冊でした。 他県の県立図書館では、地方であってもAWSやクラウド関連の書籍が一定数揃っているケースが多く、これは岡山県立図書館に限った傾向のように見えます。 読書文化自体は根付いている土地であるにもかかわらず、技術書という観点では選書が薄い。 これは図書館側の選書方針の問題という側面もありますが、裏を返せば「IT関連書籍を求める利用者の声がそれだけ少ない」ということでもあります。 岡山のIT従事者に読書習慣を持つ人が少ない、という仮説を補強する材料の一つと言えそうです。 2. ソフトウェア投資を嫌う文化 岡山のSier(システム開発会社)であっても、勤怠管理や会計処理にソフトウェアを導入せず、Excelで運用しているケースを何度も見てきました。 本業がシステム開発である企業自体が、自社の業務効率化にはソフトウェアへの投資を渋る、という状況です。 この傾向は企業だけでなく、個人のフリーランスエンジニアにも見られます。 クラウド会計ソフトを月額契約で使い続けるのではなく、確定申告の時期だけサブスクを契約してデータをエクスポートし、申告が終わるとすぐに解約するというやり方をしている人が少なくありません。 月額1,000円前後のコストを惜しむかどうかという話ではなく、「継続的にソフトウェアへお金を払う」という発想自体への抵抗感が強いように感じます。 システム開発を生業としながら、ソフトウェアへの投資に消極的というのは、なかなか皮肉な構図です。 3. 合理化・標準化を嫌い、型破りな人材を好む文化 システム開発の本質は、業務を合理化・標準化し、再現性を持たせることにあります。 その観点で見ると、岡山県民性そのものが合理化と相性が良くない側面を持っているように感じます。 例えば以下のような点です。 県内主要道路の渋滞の多さ(合理的な交通導線が整備されているとは言い難い) ウィンカーを出さずに車線変更・右左折をするドライバーが多い(ルールより経験則優先) 「とんかつラーメン」のような、効率よりも奇をてらった方向性のご当地グルメが好まれる いずれも一つ一つは些細な事象ですが、共通しているのは「ルールに則って合理化する」よりも「その場のノリ・ルーズさ」を許容する県民性です。 システム開発は良くも悪くも「決めたルール通りに動く」ことが前提の仕事なので、この県民性とは根本的に相性が悪いのかもしれません。 この傾向は、採用や評価の場面にも表れています。 会社によりますが、ルール通りに堅実に仕事を進める人材よりも、斬新なアイデアを出す型破りな人材の方が評価されやすい空気があります。 実際に岡山のシステム会社の経営者の中には、「うちの社員は色がある」ということを、むしろ自慢げに語る方もいます。 「色がある」こと自体は個性として悪いことではありませんが、システム開発という「決めたルール通りに正確に動く」ことが前提の仕事において、型破りであることを評価軸にしてしまうと、品質や再現性が犠牲になりやすいという側面もあります。 合理化を嫌う県民性と、型破りな人材を好む採用・評価の傾向は、根っこの部分でつながっているのかもしれません。 4. 第三次産業の弱さ 岡山県は製造業(第二次産業)の比率が比較的高い一方、情報通信業を含む第三次産業の集積は他の政令指定都市エリアと比べると弱いことがたびたび指摘されています。 システム開発企業やIT人材の絶対数が少なければ、当然コミュニティも育ちにくく、勉強会やカンファレンスの開催数、技術情報の流通量にも影響してきます。 「エンジニアが少ないから情報が集まらない」のか、「情報が集まらないからエンジニアが育たない・定着しない」のか、因果関係は一概には言えません。 ただ、いずれにしても第三次産業、特にIT分野の集積の薄さが、システム開発という仕事にとって向かい風になっているのは間違いなさそうです。 おわりに ここまで4つの観点から、岡山県とシステム開発の相性について考察してきました。 技術書へのアクセスのしやすさ ソフトウェアへの投資意欲 合理化・標準化を嫌い、型破りな人材を好む文化 第三次産業(IT)の集積度 いずれも「岡山だから絶対にダメ」と断言できるものではなく、あくまで傾向や仮説の域を出ません。 一方で、複数の観点から似たような傾向が見えてくるという事実は、それなりに示唆的ではないかと思います。 皆さんは、この4つの理由をどう捉えるでしょうか。 「たしかに」と感じる部分もあれば、「自分の周りは違う」と感じる部分もあるかもしれません。 もし岡山でシステム開発の仕事をしている方、あるいはこれから岡山でのキャリアを考えている方がいれば、ぜひ自分の経験と照らし合わせて考えてみてください。

はじめに この記事では、フリーランスITエンジニア向け案件紹介サービスPE-BANKについて解説します。 岡山県など地方在住者におすすめできるかも含めて、メリット・デメリットを整理しました。 PE-BANKとは PE-BANKは、ITエンジニア専門の案件紹介サービスです。 1989年創業の老舗で、エンジニア主体の共同受注モデルを採用しています。 共同受注モデルなので、契約内容に透明性があり、マージン率が公開されているため、良心的なフリーランスエージェントと言われています。 運営会社: 「株式会社PE-BANK」 PE-BANKの運営会社は株式会社PE-BANKです。 同社は、フリーランスITエンジニア向けの共同受注事業を中心に展開する企業で、1989年創業の実績ある会社です。 項目 内容 会社名 株式会社PE-BANK 設立 1989年 所在地 東京都港区高輪2-15-8 グレイスビル泉岳寺前 事業内容 ITエンジニア共同受注事業 上場 非上場 長年にわたりエンジニア主体のビジネスモデルを継続しており、全国に拠点を展開している点が特徴です。 PE-BANKの特徴 項目 内容 対応エリア 全国（主要都市に拠点あり） リモート案件 一部あり（常駐案件が中心） 案件数 非公開（全国で常時多数） 平均月単価 60万〜80万円前後 消費税表記 税抜き表示が基本 マージン率 公開制（参画期間が長いとその分マージン率が下がる仕組み、10～15％前後） 福利厚生 共済会制度あり（保険・税務サポート等） 特徴 高還元率とマージン公開の透明性が強み PE-BANKは、1989年創業の老舗フリーランスエージェントです。 エンジニア主体の「共同受注」モデルを採用し、報酬還元率の高さと透明性を重視しています。

はじめに 「なぜ中小企業ではスキルが伸びないのか」—— 転職や異動を経験した人なら、この疑問を感じたことがあるかもしれません。 大企業と比べて研修制度が整っていない、という指摘はよくあります。しかしそれだけではなく、組織文化や個人の習慣レベルに深い根本原因が存在します。 表面的な「研修がない」「予算がない」という理由の背後には、目標設定能力の欠如、学習に対する姿勢の問題、そして日常的な生活習慣まで、複合的な要因が絡み合っています。これらは一朝一夕には解決できず、組織全体の文化として根付いているケースがほとんどです。 本記事では、実際の現場で起きた事例をもとに、中小企業でスキルアップが進まないの理由を解説します。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 1. 目標設定と達成プロセスが機能しない 中小企業だとメンバーの論理的思考力や語彙力に長けた社員が少ないため、目標設定自体ができないケースが多々あります。 以下の例では、目標設定メソッドにマンダラチャートを採用しましたが、社員のスキルの低さから、目標設定ができずに終わってしまったようです。 本当にあった?エンジニアの怖い話「マンダラチャートで目標すら立てられない会社のPDCA」 —— 論理的思考力の弱さから目標設定そのものが機能しなかった事例 目標を立てる能力が弱い組織では、スキル向上の仕組みそのものが成立しません。 論理的思考力がなければ「何を・いつまでに・どうやって」という構造で考えられないため、計画は絵に描いた餅になります。 目標を設定すること自体にもスキルが必要で、適切な目標設定をできない組織にいる限り、成長は難しいのではないかと思います。 目標設定に時間がかかり過ぎる 本当にあった?エンジニアの怖い話「目標設定に四半期の約1/4を消費する会社」 —— 目標設定の仕組みが整っておらず、議論だけで大量の時間を消費した事例 目標設定のノウハウが組織に蓄積されていないと、毎回ゼロから議論を始めることになり、肝心の実行期間そのものが削られてしまいます。 さらに厄介なのは、「時間をかけた＝真剣に取り組んだ」という誤った達成感で終わってしまい、プロセス自体の非効率さが問題として認識されにくい点です。 目標設定に時間がかかること自体は個人の努力不足ではなく、仕組みが整っていない組織のサインであり、そうした環境ではスキルアップに使うべき時間がそもそも確保できません。 自分本位の考えを重視し、教科書通りの学習をしない 本当にあった?エンジニアの怖い話「勤怠ソフトのボタンをてんとう虫にする会社」 「経験」や「勘」に頼って仕事を進める文化では、教科書的な手法が「理屈っぽい」「現場をわかっていない」と軽視されがちです。 しかしこの文化のもとでは正しい方法論を学ぶ動機自体が生まれず、再現性のあるスキルが身につきません。 感覚的な判断は個人の経験に強く依存するため、他のメンバーへの知識移転もできず、組織として学習が積み上がっていかないのです。 技術への興味が薄く、知識が広がらない 事例 これは、複数の物理サーバーを管理するプロジェクトの事例です。 あるプロジェクトで、複数のサーバーに対して同時にコマンドを実行できるSSHクライアント「Rlogin」を選定・採用しました。 このRloginを使うことで、同じ作業を各サーバーに個別に実施する手間が大幅に削減でき、ヒューマンエラーのリスクも低減できます。 導入した担当者は事前に動作検証を行い、Rloginがプロジェクトの要件にも合致していることを確認した上での採用でした。 ところが、このツールをプロジェクトで展開しようとしたとき、ベテラン社員から思わぬ反発を受けました。 「Teraterm以外のツールは聞いたことがない。有名なツールではない。」 という理由だけで、「基礎を無視したやり方だ」「なぜ実績のあるツールを使わないのか」と担当者に対して批判的な意見が述べられました。 ツールの選定基準として本来評価すべきは、プロジェクトとの適合性のはずです。　しかし実際には、「自分が知っているかどうか」が唯一の判断基準になっていました。 結果として、このツールの採用は見送られ、効率の悪い従来の手作業が継続されました。 理由 ツールの知名度や自分の馴染みで技術を評価する文化が存在すると、合理的な判断ができなくなります。 この姿勢の根本には、技術への好奇心の欠如があります。 「知らないものは怖い」「今のやり方で困っていない」という意識が強いと、新しい技術や手法を積極的に学ぼうとする動機が生まれません。その結果、知識が特定の範囲に固定されたまま広がらず、技術の進化に取り残されていきます。 また、このような文化では新しい提案をした人が「基礎がわかっていない」と逆に批判されるため、若手エンジニアの学習意欲を削ぐ効果もあります。 知識を広げようとする行動がリスクになる組織では、現状維持が最も合理的な選択になってしまいます。 2. 学習を阻害する生活習慣 事例 これは、特定の1社ではなく、複数の中小企業で共通して見られた傾向をまとめた事例です。 スキルアップには継続的な努力が必要です。しかし、日常の生活習慣がその継続を根本から阻害しているケースが少なくありません。 具体的には、 業務後にパチンコや競馬などのギャンブルを日課にしている 喫煙の頻度が非常に高く、就業中も離席が多い 飲酒量が多く、翌朝に疲労が残った状態で出勤する スマートフォンのSNSやゲームに長時間費やしている といった習慣を持つ人が、複数の中小企業の現場で一定数見られました。

はじめに エンジニアのキャリアを考えるとき、「東京に行けばもっと最新技術に触れられる」「地方にいては技術力が遅れてしまう」と考える方は多いのではないでしょうか。 確かに東京には多くのIT企業が集中しており、案件数も豊富で最新技術が採用されやすい環境があります。 しかし、東京に上京したからといって、必ずしも最新技術を習得できるわけではありません。 この記事では、東京と地方のエンジニア環境を比較しながら、上京を検討しているエンジニアが知っておくべき現実について解説します。 東京のメリット 案件数・技術スタックの多様性 東京にはIT企業が数多く存在し、案件数も地方と比べてはるかに多く、プロジェクトで採用される技術スタックも比較的新しいものが採用される傾向があります。 最新のクラウド技術やモダンなフロントエンドフレームワーク、AIを活用したシステム開発など、先進的な取り組みをしている企業も多く存在します。 東京のデメリット 案件数が多い分、「案件ガチャ」がある 日本国内の企業のほとんどは中小企業です。案件数が多いがゆえに、以下のようなケースにアサインされるリスクも存在します。 マイナーな技術を採用したプロジェクト: 需要が限定的で、転職市場での汎用性が低い技術を使い続けることになる システム開発と関連性が低い作業: 運用監視や単純なデータ入力など、エンジニアとしての成長につながりにくい業務 レガシーシステムの保守: 最新技術とはかけ離れた古いシステムの維持管理 人間関係の課題: プロジェクトのステークホルダーとのコミュニケーションがうまくいかなかったり、メンバーの技術スキルが低く、レビューやサポートに想定以上の工数を取られる いわゆる 「案件ガチャ」 と呼ばれる状況があり、良い案件に当たればスキルアップのチャンスになりますが、そうでない場合のリスクも無視できません。 上京してもスキルアップできる保証はなく、運次第という側面があるのが現実です。 地方のメリット 使用技術の汎用性 地方で仕事をする場合でも、技術スタック自体は必ずしも時代遅れではありません。 マイナーな技術ではなく、業界で広く使われているメジャーな技術を用いた開発が多いため、習得したスキルが汎用的に活かせるケースが少なくありません。 昔からあるJava、C#など需要の高いプログラミング言語 AWS、Azureなど広く普及しているクラウドサービス SQL Serverやpostgrresqlなど標準的なデータベース 取引先は都市部の企業 地方に拠点を置いていても、実際の取引先はほぼ東京・大阪などの都市部の企業になることが多いです。 地方に就職したからといって、仕事内容が大きく変わるわけではありません。 リモートワークやオンライン会議の普及により、物理的な距離のハンデはかつてより小さくなっています。 生活コストが安い 地方と東京では生活コストに大きな差があります。 項目 東京 地方（岡山など） 家賃（1K） 8〜12万円 4〜6万円 駐車場代 2〜5万円 3,000〜5,000円 物価全般 高い 比較的安い 年間で50万円以上の差が出ることも珍しくありません。

はじめに この記事では、 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.