ID:85732さん

# プロジェクト概要 1,200装置規模の大規模ネットワーク運用業務において、Power Automate Desktop（PAD）を活用した業務自動化プロジェクトをプレイングリーダーとして推進。 ネットワーク機器への設定投入準備の効率化、および顧客ごとに異なる稼働率報告資料の自動作成という計3案件に取り組んだ。 業務課題の抽出から要件定義、設計、実装、テスト、運用展開まで一貫して携わり、技術的な実装とチームマネジメントを並行して担当した。 # チーム情報・担当範囲 - **体制：** 各案件2名、3案件で延べ6名 - **役割：** プレイングリーダー - **担当工程：** 課題抽出、要件定義、設計、実装、テスト、運用展開 - **使用技術：** Power Automate Desktop、Excel、VBA、Word、サイボウズ社製業務システム 自身は各案件の課題整理、実装方針の検討、フロー設計・実装に加え、メンバーへの作業割り振りや進捗管理を担当。 既存業務の手順を整理し、担当者が変わっても一定の品質で運用できる仕組みづくりを重視した。 # 開発・実装内容① ネットワーク機器への設定投入準備の効率化 ## 【概要】 ネットワーク機器への設定投入に必要なExcelシートの作成を効率化し、入力ミス防止機能を実装した。 ## 【課題・問題点】 従来は設定投入に必要な情報の整理や入力を手作業で行っており、作業時間の削減と入力ミスの防止が課題だった。 また、実際の設定投入は外部ネットワークに接続できない監視端末から実施する必要があり、設定投入そのものの自動化は困難だった。 ## 【打ち手・使用技術】 - VBAを活用した設定投入用Excelシートの作成 - 入力ミスを防止する機能の実装 - ネットワーク環境の制約を考慮し、自動化可能な準備工程を切り分け - 手順の整理と標準化による作業品質の安定化 実際のネットワーク機器への設定投入は監視端末から手動で実施し、投入前の準備工程を効率化した。 ## 【成果】 **設定投入に関する作業時間を従来約20分から数分に短縮。** 入力ミスの防止と作業手順の標準化にも貢献した。 # 開発・実装内容② 顧客向け稼働率報告資料の自動作成 ## 【概要】 サイボウズ社製業務システムに登録された情報を活用し、顧客向けの稼働率報告資料をWord形式で作成する業務を自動化した。 ## 【課題・問題点】 従来は業務システムから必要な情報を確認し、報告資料へ転記する定型作業に工数が発生していた。 ## 【打ち手・使用技術】 - Power Automate Desktopによる業務システムの画面操作を自動化 - 必要なデータの取得・転記処理をフロー化 - Word形式の報告資料作成に必要な定型処理を自動化 - 既存の作業手順を整理し、再現性のある処理を構築 ## 【成果】 **報告資料1件あたり約10分の作業時間を削減。** 手作業による転記負担を軽減し、資料作成の効率化を実現した。 # 開発・実装内容③ 複数回線を対象とした稼働率報告資料の自動作成 ## 【概要】 複数のネットワーク回線を提供する別の顧客向けに、回線ごとの稼働率をExcelで計算し、Word形式の報告資料に反映する業務を自動化した。 ## 【課題・問題点】 複数回線の情報を扱うため、データ取得・整理に加え、Excelでの計算とWordへの転記が必要だった。 手作業では工程が多く、資料作成に時間を要していた。 ## 【打ち手・使用技術】 - Power Automate Desktopによる業務システムの画面操作とデータ取得の自動化 - Excelを活用した複数回線の稼働率計算 - 計算結果をWord形式の報告資料へ反映 - 顧客固有の報告要件に合わせた処理フローの設計・実装 ## 【成果】 **報告資料1件あたり約10分の作業時間を削減。** 複数回線の計算・転記工程を効率化し、報告資料作成の負担軽減に貢献した。 # プロジェクト全体の成果 - **計3案件の業務自動化・効率化を実現** - ネットワーク機器への設定投入準備を含む作業時間を約20分から数分に短縮 - 顧客別の稼働率報告資料作成をそれぞれ1件あたり約10分短縮（2案件で各1件作成した場合、合計約20分削減） - 既存業務システムとExcel・Wordを組み合わせた自動化フローを構築 - ネットワーク環境の制約や顧客固有の要件を考慮した自動化を実現 - 作業手順の標準化と入力ミス防止による品質向上 - プレイングリーダーとして、実装とメンバー管理を並行して推進 本プロジェクトでは、既存の運用環境やセキュリティ上の制約を踏まえ、自動化可能な工程を見極めながら改善を推進した。 単なる作業時間の短縮だけでなく、課題抽出から技術的な実装、チームでの開発、運用への定着まで一貫して担当できることが自身の強みである。

# プロジェクト経験概要 1,200装置規模の大規模ネットワークを監視・運用するネットワークセンターにおいて、Microsoft Copilot Studioを活用したAIエージェント開発プロジェクトを推進。 運用業務の効率化、担当者のスキル向上、障害対応の迅速化を目的として、AIエージェントの設計・開発および運用改善に取り組んでいる。 これまでに、対応履歴の自動要約とトラフィック異常検知を支援する2体のAIエージェントを開発し、本番運用へ展開した。 現在は、SharePointをナレッジ基盤として活用し、オーケストレーターと3体の専門エージェントを連携させるマルチエージェント構成の開発を推進している。 # チーム情報・担当範囲 - **チーム体制：** 3名 - **役割：** プレイングリーダー（PL相当） - **担当工程：** 企画、課題抽出、要件整理、設計、実装、テスト、運用展開、運用改善 - **使用技術：** Microsoft Copilot Studio、SharePoint、SharePointリスト、生成AI、プロンプト設計 自身が中心となってプロジェクトを推進し、開発方針の検討、メンバーへの作業分担、進捗管理を担当。 各エージェントの開発はメンバーと分担し、自身も設計・実装に参加するプレイングリーダーとして活動している。 開発後も現場の利用者が継続的にナレッジや出力品質を改善できる仕組みづくりを重視している。 # 開発・実装内容① 運用業務を支援するAIエージェントの開発・運用改善 ## 【概要】 ネットワーク運用業務の効率化を目的として、Microsoft Copilot Studioを活用した2体のAIエージェントを開発し、本番運用へ展開した。 対応履歴の会議用自動要約と、約150回線を対象としたトラフィックレポートの異常検知支援を実現している。 ## 【どのような機能の開発・実装か】 ### ① 対応履歴の自動要約 ネットワーク運用における対応履歴をAIで要約し、会議での情報共有に活用する機能。 現在は週約10回の頻度で利用されている。 ### ② トラフィック異常検知支援 約150回線規模のトラフィックレポートを対象に、通常と異なる傾向や異常の確認を支援する機能。 顧客向けの月次レポート作成・確認業務で、月1回の頻度で利用されている。 ## 【課題・問題点】 ネットワーク運用業務では、対応履歴の確認やトラフィックレポートの分析など、情報の整理・確認に工数が発生していた。 これらの定型的な情報確認業務をAIで支援することにより、運用担当者の負担軽減と業務効率化を図る必要があった。 また、対応履歴の自動要約エージェントについては、本番運用を開始した後、出力される要約の情報量や記載粒度にばらつきが生じる課題が明らかになった。 同じ用途の会議資料であっても、要約の詳しさが一定ではないため、安定した品質で情報共有できる仕組みが求められている。 ## 【打ち手・使用した技術】 - Microsoft Copilot Studioを活用したAIエージェントの設計・開発 - 対応履歴を会議用に要約する業務支援機能の実装 - 約150回線のトラフィックレポートを対象とした異常検知支援機能の実装 - 実際のネットワーク運用業務への展開 - 本番利用を通じた出力品質の課題抽出 - プロンプトの見直しと、期待する出力例を整理した見本集の整備 ### 【設計・運用上の工夫】 対応履歴の自動要約については、AIエージェントを開発して終わりにせず、本番運用で明らかになった出力品質の課題に対して継続的な改善を進めている。 具体的には、要約の情報量や記載粒度を一定にするため、プロンプトの見直しと、期待する要約の書き方を示す見本集の作成に取り組んでいる。 見本集は開発担当者だけで完成させるのではなく、現場のメンバーが適切な要約例や改善点を持ち寄り、継続的に追加・更新していく方針とした。 利用者の知見を蓄積し、プロンプト改善にも活用することで、特定の担当者に依存せず、チーム全体でAIの出力品質を高めていく運用を目指している。 ## 【成果】 **2体のAIエージェントを実装し、いずれも本番運用中。** - 対応履歴の自動要約：週約10回の利用実績 - トラフィック異常検知支援：約150回線を対象に月1回利用 - 本番運用で発見した要約品質のばらつきに対し、プロンプト改善と見本集の整備を推進中 AIエージェントを実際のネットワーク運用業務へ組み込み、継続的に利用できる仕組みを実現した。 作業時間削減などの定量的な効果や、要約品質の改善効果については、今後検証する予定である。 # 開発・実装内容② マルチエージェントによる運用ナレッジ活用基盤の構築 ## 【概要】 運用担当者のスキル向上と障害対応の迅速化を目的として、Microsoft Copilot StudioとSharePointを活用したマルチエージェント構成を開発中。 オーケストレーターが利用者の質問内容に応じて3体の専門エージェントへ自動的に処理を振り分ける構成を採用している。 ## 【どのような機能の開発・実装か】 ### ① 用語集エージェント ネットワーク運用に関する専門用語や業務知識を参照し、利用者の疑問解消を支援する機能。 SharePointリストを用語集の管理基盤として活用し、利用者自身が用語や知識を追加・更新できる仕組みを構築。 更新された情報をAIエージェントの回答に反映できる構成としている。 ### ② スキルアップ支援エージェント 社内の業務手順書や取扱資料などを活用し、運用担当者の知識習得とスキル向上を支援する機能。 担当者が必要な業務知識へ効率的にアクセスできる環境を目指している。 ### ③ 対応支援エージェント ネットワーク運用における特異対応時に、関連する業務手順や取扱資料などの情報取得を支援する機能。 必要な情報を迅速に確認できるようにすることで、障害対応の迅速化を目指している。 ### ④ オーケストレーター 利用者からの質問内容に応じて、用語集、スキルアップ支援、対応支援の各専門エージェントへ処理を自動的に振り分ける構成。 利用者が個別のエージェントを意識せず、目的に応じた業務支援機能を利用できる仕組みを目指している。 ## 【課題・問題点】 ネットワーク運用では、障害対応に必要な知識や手順が多岐にわたり、担当者ごとの経験や習熟度によって情報の確認・判断に要する時間が異なる。 業務知識は用語集、業務手順書、取扱資料など複数の情報源に分かれており、必要な情報を探す際に複数の資料を確認する必要がある。 また、新たな業務知識や運用上の知見を継続的に活用するためには、AIエージェントの開発担当者だけでなく、現場の利用者自身がナレッジを追加・更新できる仕組みが必要だった。 ## 【打ち手・使用した技術】 - Microsoft Copilot Studioを活用したAIエージェントの設計・開発 - SharePoint上への用語集、業務手順書、取扱資料の整理 - SharePointリストを活用した用語集の管理・更新機能の構築 - 利用者が追加・更新したナレッジをAIエージェントの回答へ反映する構成の実装 - オーケストレーターによる質問内容に応じた専門エージェントの自動振り分け - 3名体制での開発分担、進捗管理、設計・実装の推進 ### 【技術選定・設計上の工夫】 #### Microsoft Copilot Studioの採用 社内で利用可能なMicrosoft Copilot環境を活用できることから、Microsoft Copilot Studioを採用した。 既存のMicrosoft 365環境やSharePoint上の業務資料を活用する方針とし、新たな利用環境の導入負担を抑えることを重視した。 #### マルチエージェント構成の採用 用語確認、スキルアップ支援、特異対応支援では、それぞれ求められる情報や役割が異なる。 そのため、すべての機能を単一のエージェントに集約するのではなく、役割別の3体の専門エージェントに分離。 オーケストレーターが質問内容に応じて適切なエージェントを自動的に選択する構成とした。 利用者の使いやすさと、機能ごとの管理・改善のしやすさを両立することを目指している。 #### 現場主体でナレッジを育てる仕組み SharePointリストを用語集の管理基盤として採用し、現場の利用者自身が新しい用語や知識を追加・更新できる構成とした。 AIエージェントの回答に利用する情報を現場で継続的に充実させることで、開発担当者だけに依存しないナレッジ管理を目指している。 ## 【成果・現在の進捗】 **3名体制のプレイングリーダーとして、オーケストレーターと3体の専門エージェントによるマルチエージェント構成の開発を推進中。** SharePointリストを利用者が更新し、その内容をAIエージェントの回答に反映できる仕組みを構築した。 現在は、用語集、スキルアップ支援、対応支援の各機能をメンバーと分担して開発している。 運用担当者のスキル向上や障害対応の迅速化に関する定量的な改善効果は、運用開始後に検証する予定である。 # プロジェクト全体の成果・発揮した強み - **Microsoft Copilot Studioを活用したAIエージェント2体を開発し、本番運用へ展開** - **対応履歴の自動要約エージェントを週約10回利用** - **約150回線を対象としたトラフィック異常検知支援エージェントを月1回利用** - 本番運用後の課題を踏まえ、プロンプトの見直しと要約見本集の整備を推進 - 現場のメンバーが見本集を継続的に追加・改善する運用を検討 - オーケストレーターと3体の専門エージェントによるマルチエージェント構成を開発中 - SharePointリストを活用し、利用者自身がナレッジを更新できる仕組みを構築 - 3名体制のプレイングリーダーとして、開発方針の検討、作業分担、進捗管理、設計・実装を推進 本プロジェクトでは、AIエージェントの設計・開発に加え、本番運用を通じた課題発見と継続的な改善にも取り組んでいる。 特に、AIの出力品質を開発担当者だけで管理するのではなく、現場のメンバーが見本集やナレッジを継続的に育て、チーム全体で品質を高める仕組みを重視している。 ネットワーク運用の実務経験とAI技術を組み合わせ、現場課題の整理から開発、チームマネジメント、運用改善まで一貫して推進できることが自身の強みである。

# プロジェクト経験概要 1,200装置規模の大規模ネットワークを監視・運用するネットワークセンターにおいて、対応履歴管理システムのUI改善・業務品質向上プロジェクトを推進。 障害対応履歴の入力品質向上と記録業務の効率化を目的として、過去3年間に蓄積された約1,100件の対応履歴データを分析し、実際の利用状況に基づいた入力画面の改善を実施した。 データ分析から課題抽出、改善方針の検討、UI改修、効果確認、運用定着まで一貫して担当。 **改善後3か月以上にわたり、対応履歴の入力漏れゼロを維持した。** # チーム情報・担当範囲 - **チーム体制：** 3名 - **役割：** 改善活動の主担当 - **担当工程：** 課題抽出、データ分析、改善方針の検討、UI改修、効果確認、運用定着 - **使用技術：** Excel、CSV、サイボウズ社製業務システム 自身が中心となって改善活動を推進し、過去データの分析、改善対象の選定、入力画面の改修を主担当として実施した。 実際のネットワーク運用業務に従事する立場から、障害対応が集中する状況でも必要な情報を記録しやすい画面構成を重視した。 # 開発・改善内容① 対応履歴データの分析と入力画面のUI改善 ## 【概要】 ネットワーク障害の対応履歴を管理する業務システムについて、過去の蓄積データを分析し、実際の利用状況に基づいて入力項目と画面構成を見直した。 サイボウズ社製業務システムから過去3年間・約1,100件の対応履歴をCSV形式で出力し、Excelで分析を実施。 分析結果をもとに、使用頻度の低い項目の削除と入力順序の変更を行った。 ## 【どのような機能の開発・改善か】 ### ① 対応履歴データの分析 - 過去3年間に蓄積された約1,100件の対応履歴をCSV形式で出力 - Excelを用いて入力項目ごとの使用状況を集計・分析 - 利用頻度の低い項目を特定 - 分析結果を改善対象の選定に活用 ### ② 入力画面のUI改善 - 使用頻度の低い不要な入力項目を削除 - 実際の業務に合わせて入力項目の順序を変更 - 必要な情報を入力しやすい画面構成へ見直し - 改善後の入力状況を確認し、運用定着をフォロー ## 【課題・問題点】 ネットワークセンターでは、日常的な障害対応に加え、台風などの影響によって複数の障害が同時に発生する場合がある。 こうした状況では、障害復旧を優先しながら、発生状況や対応経過を正確に記録する必要がある。 一方、既存の対応履歴管理システムには利用頻度の低い入力項目が存在し、実際の業務に必ずしも適した画面構成となっていなかった。 入力項目の多さや配置が記録作業の負担となる可能性があり、対応履歴の入力漏れも発生していた。 特に障害対応が集中する場面でも、担当者が迷わず必要な情報を入力できる仕組みが求められていた。 ## 【打ち手・使用した技術】 ### ① 実データに基づく課題分析 担当者の感覚や経験だけで改善内容を決定するのではなく、過去3年間・約1,100件の対応履歴データを分析した。 CSV形式で抽出したデータをExcelで集計し、各入力項目の使用頻度を確認。 実際の利用状況を根拠として、削除・見直しの対象となる項目を選定した。 ### ② 入力項目の最適化 分析結果に基づき、使用頻度の低い不要な項目を削除した。 入力項目を単純に減らすだけでなく、現場での記録作業の流れに合わせて入力順序を変更。 必要な情報を入力しやすい画面構成へ改善した。 ### ③ 改善後の運用定着と効果確認 UI改修後も入力状況を確認し、改善した画面が実際の運用で継続して使用できるかをフォローした。 台風時など複数の障害対応が集中する場面も考慮し、作業のしやすさと記録品質の両立を重視した。 ## 【技術選定・設計上の工夫】 ### データに基づく改善対象の選定 約1,100件の実データをExcelで分析することで、入力項目の利用実態を把握した。 既存システムのデータをCSV形式で出力して分析する方法を採用し、追加の開発環境を構築せずに改善対象を特定した。 ### 既存システムを活用したUI改善 新たなシステムを開発するのではなく、既存の対応履歴管理システムの入力項目と配置を見直す方針とした。 現場で使用しているシステムを維持しながら改善することで、業務フローを大きく変更せず、入力作業の負担軽減を図った。 ### 障害対応が集中する環境を考慮した画面設計 ネットワーク運用では、複数の障害対応が同時に発生する場合でも、対応履歴を正確に残すことが重要となる。 そのため、平常時の操作性だけでなく、対応が集中する状況でも必要な項目を入力しやすい画面構成を重視した。 ## 【成果】 **改善後3か月以上にわたり、対応履歴の入力漏れゼロを維持した。** 主な成果は以下のとおり。 - 過去3年間・約1,100件の対応履歴データを分析 - 分析結果に基づき、不要な入力項目の削除と入力順序の変更を実施 - 改善後3か月以上、入力漏れゼロを確認 - 実際の運用業務に合わせた入力画面へ改善 - データ分析からUI改修、効果確認、運用定着まで一貫して担当 利用者満足度や入力時間の削減については定量的な測定を実施していないが、現場での作業を通じて、複数の障害対応が集中する状況でも記録しやすい画面構成になったと評価している。 # プロジェクト全体の成果・発揮した強み 本プロジェクトでは、業務システムの改善を担当者の主観だけで判断せず、約1,100件の実データを根拠として改善対象を特定した。 また、自身がデータ分析とUI改修を主担当として実施し、改善後の入力状況まで確認することで、単発の画面変更ではなく、実際の業務品質向上につなげた。 特に、ネットワーク運用の現場経験を活かし、障害対応が集中する状況でも使いやすい仕組みを検討できたことが強みである。 **データ分析による課題発見から、改善方針の策定、システム改修、成果検証まで一貫して推進できることを示したプロジェクトである。**

# プロジェクト経験概要 AWSのクラウドインフラ構築と生成AI活用技術の習得を目的として、TerraformによるInfrastructure as Code（IaC）とAmazon Bedrockを組み合わせたAI監視エージェントを個人開発した。 VPC・EC2・RDS・ALBによる基本的な3層アーキテクチャを構築し、Terraformでインフラ構成をコード化。 さらに、Amazon CloudWatch・AWS Lambda・Amazon Bedrock・Slackを連携させ、アラーム発生後の分析、対応要否の判定、通知までを自動化する仕組みを実装した。 Amazon Pollyによる音声確認機能に加え、Slackのリアクションを利用したフィードバック収集・集計・判定改善の仕組みも開発した。 基本判定テストでは10件中10件正解、統合テストでは3パターンすべて成功するなど、実装だけでなく動作検証と品質評価まで取り組んだ。 # チーム情報・担当範囲 - **開発体制：** 個人開発 - **役割：** 設計・開発・検証の全工程を担当 - **担当工程：** 要件整理、アーキテクチャ設計、インフラ構築、IaC化、機能実装、テスト、技術検証 - **使用技術：** AWS、Terraform、Amazon VPC、Amazon EC2、Amazon RDS、Application Load Balancer、Amazon CloudWatch、AWS Lambda、Amazon Bedrock、Amazon Polly、Amazon DynamoDB、Slack API 約12年間の通信インフラ運用・障害対応経験を背景に、実際の監視業務で発生するアラーム確認や対応判断の負担を軽減することをテーマとして取り組んだ。 AWSによるインフラ構築から生成AI連携、外部サービスとの連携、判定精度の検証まで一貫して担当した。 なお、本プロジェクトは個人学習・技術検証を目的としたポートフォリオであり、商用環境でのAWS構築・運用案件ではない。 # 開発・実装内容① TerraformによるAWS 3層アーキテクチャの構築 ## 【概要】 AWSの基本的なインフラ設計・構築技術の習得を目的として、VPC・EC2・RDS・ALBを組み合わせた3層アーキテクチャを構築した。 さらに、Terraformを活用してインフラ構成をコード化し、Infrastructure as Code（IaC）による構成管理を実践した。 ## 【どのような機能の開発・実装か】 - Amazon VPCによるネットワーク環境の構築 - Amazon EC2によるアプリケーション実行環境の構築 - Amazon RDSによるデータベース環境の構築 - Application Load Balancerによる通信の振り分け - Terraformによる3層構成のコード化 ## 【課題・問題点】 オンプレミスの通信インフラ運用経験はある一方、AWSによるクラウドインフラの設計・構築経験を習得する必要があった。 また、クラウド環境では手動操作によるリソース構築だけでなく、構成をコードとして管理し、再現性を確保する考え方を理解することが重要だと考えた。 ## 【打ち手・使用した技術】 VPC・EC2・RDS・ALBを組み合わせ、ネットワーク、アプリケーション、データベースから構成される基本的な3層アーキテクチャを構築した。 その後、Terraformを使用して3層構成をIaC化。 AWSの各サービスの役割と依存関係を理解しながら、手動操作に依存しないインフラ構成管理を実践した。 なお、Terraformによる構築対象は3層アーキテクチャであり、監視・生成AI連携機能については別途構築した。 ## 【成果】 - VPC・EC2・RDS・ALBによる基本的な3層アーキテクチャを構築 - Terraformによるインフラ構成のコード化を実施 - AWSの基本的なネットワーク・コンピューティング・データベース構成とIaCの実践経験を獲得 # 開発・実装内容② Amazon Bedrockを活用したAI監視エージェントの開発 ## 【概要】 Amazon CloudWatchによるアラーム検知と、Amazon Bedrockによる生成AI分析を組み合わせ、対応が必要なアラームを選別してSlackへ通知するAI監視エージェントを開発した。 ## 【どのような機能の開発・実装か】 以下の処理を連携させた。 1. Amazon CloudWatchで監視アラームを検知 2. アラームを契機にAWS Lambdaを起動 3. Lambdaからアラーム情報をAmazon Bedrockへ送信 4. Bedrockがプロンプトに基づいてアラーム内容を分析し、対応要否を判定 5. 対応が必要と判断されたアラームをSlackへ通知 ## 【課題・問題点】 通信インフラの監視業務では、アラーム発生後に内容を確認し、対応の必要性を判断する工程に人的工数が発生する。 また、発生したアラームを一律に通知する方式では、監視担当者が確認すべき情報を選別する必要がある。 そこで、既存の閾値監視と生成AIによる内容分析を組み合わせ、対応判断を支援する仕組みを検討した。 ## 【打ち手・使用した技術】 - Amazon CloudWatchによるアラーム検知 - AWS Lambdaによるイベント起点の分析処理 - Amazon Bedrockを用いたアラーム内容の分析 - プロンプトによる対応要否の判定 - Slackへの通知処理の実装 - テストアラームを使用した一連の動作検証 ## 【技術選定・設計上の工夫】 ### 生成AIを活用した通知対象の選別 すべてのアラームを一律にSlackへ通知するのではなく、Bedrockによる分析結果を用いて対応要否を判断する構成とした。 単純な閾値超過の検知に加え、アラーム内容を生成AIで分析することで、監視担当者が確認すべき情報の絞り込みを目指した。 ### イベント駆動型の処理構成 CloudWatchのアラームを契機にLambdaを起動し、分析から通知までを実行する構成とした。 常時実行するサーバーを用意せず、アラーム発生時に必要な処理を実行する仕組みを採用した。 ## 【成果】 **テストアラームの発報からLambdaの起動、Bedrockによる分析、Slack通知までの一連の動作を確認した。** AWSの監視サービスと生成AIを組み合わせた、イベント駆動型のAI監視エージェントを実装した。 # 開発・実装内容③ Amazon Pollyによる音声確認機能の実装 ## 【概要】 テキストによる通知に加え、アラームのエラー内容を音声で確認できる機能をAmazon Pollyで実装した。 ## 【どのような機能の開発・実装か】 - Amazon Pollyを使用したエラー情報の音声化 - URLから音声情報を確認できる仕組みの実装 - テキスト以外の方法でもアラーム内容を把握できる機能の追加 ## 【課題・問題点】 監視業務における通知はテキストによる情報確認が中心となるため、状況に応じて別の方法でも内容を把握できる仕組みを検討した。 ## 【打ち手・使用した技術】 Amazon Pollyを利用して、アラームのエラー内容を日本語音声で確認できる機能を開発。 URLから音声を確認できる構成とし、監視情報をテキストと音声の両方で扱えるようにした。 ## 【成果】 **Amazon Pollyを用いた音声確認機能を実装し、URLからエラー内容を音声で確認できることを検証した。** # 開発・実装内容④ AI判定の精度検証とフィードバック改善基盤の構築 ## 【概要】 AI監視エージェントの判定品質を評価し、利用者からのフィードバックを今後の判定改善に活用できる仕組みを開発した。 AWS公式ドキュメントをもとにした基本判定テストに加え、複数サービスのログ分析、Slackリアクションによるフィードバック収集、DynamoDBへの記録・集計、パターン別信頼度計算、状態更新処理を実装した。 ## 【どのような機能の開発・実装か】 ### ① AI判定精度の検証 AWS公式ドキュメントをもとにした10件のログ判定テストを実施。 PriorityおよびTeamの判定結果を期待値と照合した。 ### ② 複数サービスのログ分析 既存のLambdaを拡張し、複数のAWSサービスから取得したログを分析できる構成へ変更した。 単一のエラーだけでなく、複数サービスにまたがる問題を扱える機能を実装した。 ### ③ Slackフィードバック収集 Slack Event APIを利用し、メッセージへのリアクションをフィードバックとして受け取るLambda関数を実装。 リアクションの種類に応じてフィードバックを分類し、DynamoDBへ記録する仕組みを構築した。 ### ④ フィードバック集計・信頼度計算 DynamoDBに記録したフィードバックを集計するLambda関数を実装。 フィードバック件数の集計に加え、パターン抽出と信頼度計算の処理を構築した。 ### ⑤ 状態更新・統合テスト フィードバック内容に応じてDynamoDB上の状態を更新する処理を実装。 単純・中程度・複雑の3パターンについて、状態更新と一連の処理を検証した。 ## 【課題・問題点】 生成AIによるアラーム分析では、回答が得られるだけでなく、判定の妥当性を確認することが重要となる。 特に、実際の監視業務では誤判定が対応の遅れや不要な作業につながる可能性がある。 また、基本的なアラームだけでなく、複数サービスにまたがる問題への対応や、利用者が判定結果を評価できる仕組みも必要だと考えた。 ## 【打ち手・使用した技術】 ### 基本判定の定量評価 AWS公式資料をもとにした10件のテストデータを用意し、AIが出力したPriorityとTeamの判定結果を期待値と比較した。 ### フィードバックを活用する設計 判定結果への評価を収集する方法として、利用者が日常的に使用できるSlackリアクションを採用した。 リアクションをLambdaで受け取り、DynamoDBへ記録する構成とした。 さらに、蓄積されたフィードバックを集計し、パターン別の信頼度計算へつなげる処理を実装した。 ### 複雑なケースを想定したテスト 単純なフィードバックだけでなく、複数回のリアクションによって状態が変化するケースも用意。 状態遷移とデータ更新が想定どおりに行われるかを検証した。 ## 【成果】 ### AIの基本判定精度 **10件中10件正解（テストデータにおける正答率100%）** - Priority判定：10/10件正解 - Team判定：10/10件正解 - 総合判定：10/10件正解 ### 統合テスト **3パターン中3パターン成功** - 単純なケース：成功 - 中程度のケース：成功 - 複雑なケース：成功 ### その他の実装・検証成果 - 複数サービスのログ分析機能を実装 - Slack Event APIを利用したフィードバック受付機能を構築 - DynamoDBへのフィードバック記録処理を実装 - フィードバックのバッチ集計処理を実装 - パターン別の信頼度計算処理を実装 - フィードバックに応じた状態更新処理を検証 なお、正答率100%は用意した10件の基本判定テストでの結果であり、未知の障害や複雑な障害を含む実運用全体の精度を示すものではない。 また、Slackの実リアクションを用いた統合テストは未実施であり、フィードバック処理・集計・信頼度計算についてはテスト環境での動作検証段階である。 # プロジェクト全体の成果・発揮した強み - **VPC・EC2・RDS・ALBによる3層アーキテクチャを構築** - **Terraformによる3層構成のIaC化を実施** - **CloudWatch・Lambda・Bedrock・Slackを連携させたAI監視エージェントを開発** - **Amazon Pollyによるエラー情報の音声確認機能を実装** - **基本判定テスト10件中10件正解** - **状態更新を含む統合テスト3パターンすべて成功** - Slack Event API・Lambda・DynamoDBを活用したフィードバック改善基盤を構築 - インフラ構築、AI連携、外部API連携、品質検証まで個人で一貫して実施 本プロジェクトでは、約12年間の通信インフラ運用・障害対応経験を活かし、監視業務で発生するアラーム確認や対応判断の負担を軽減する仕組みをAWS上で設計・実装した。 単にAWSの各サービスを利用するだけでなく、TerraformによるIaC化、生成AIを用いた判断処理、フィードバックを蓄積する仕組み、判定精度の評価まで取り組んだ。 **インフラ運用で培った課題意識を、クラウド技術と生成AIを組み合わせた具体的なシステムとして実装・検証できることが自身の強みである。** # 公開アウトプット 開発内容、実装過程、テスト結果をZennで公開。 https://zenn.dev/yukitech_oki/books/2e3ad9d5cac3b7/viewer/5cd5d3

# プロジェクト経験概要 KDDIグループ企業のネットワークセンターにおいて、約1,200装置規模の通信ネットワークを対象とした24時間365日の監視・運用および障害復旧対応に従事。 海底中継線を含む通信インフラの安定稼働を支えるため、Zabbix、Grafana、外部ベンダー製監視ツール、Tera Termなどを活用し、障害検知から一次切り分け、現地保守員への作業指示、関係部署との調整、顧客連絡、復旧確認まで担当している。 障害対応では、監視情報に加え、過去の類似障害の対応経験、ケーブルルート、地理的条件などを関連付け、直接確認できない現地の状況を推定することを重視している。 また、障害状況や対応方針を手書きの図で可視化し、新任者や関係者と認識を共有。限られた人員での復旧対応と人材育成の両立に取り組んでいる。 # チーム情報・担当範囲 - **チーム体制：** 2名×5チーム、計10名のシフト体制 - **勤務体制：** 24時間365日の監視・運用 - **役割：** ネットワーク監視・障害復旧対応、新任者OJT - **担当工程：** 監視、障害検知、一次切り分け、復旧対応の調整、顧客連絡、復旧確認、運用改善 - **使用技術：** Zabbix、Grafana、外部ベンダー製監視ツール、Tera Term、ネットワーク機器 各勤務帯では2名でネットワーク監視と障害対応を担当。 自身は監視アラームの確認、障害箇所の一次切り分け、現地保守員への作業指示、関係部署への情報共有、顧客への障害連絡などを担当している。 障害の緊急度や対応状況に応じて役割を柔軟に分担し、通常監視を継続しながら復旧対応を推進している。 また、入社4年目から新任者1名のOJTを担当。実際の障害対応を通じて、技術的な切り分けや現地保守員への指示方法を指導している。 # 技術的な対応内容① 大規模ネットワークの監視・障害切り分け ## 【概要】 約1,200装置規模の通信ネットワークに対し、各種監視ツールを使用したアラーム監視と障害発生時の一次切り分けを担当。 アラームの時系列、対向装置の状態、光受信レベル、過去の対応履歴、ケーブルルートなど、複数の情報を組み合わせて障害箇所を推定している。 ## 【どのような技術的対応か】 - Zabbix、Grafana、外部ベンダー製監視ツールによるネットワーク監視 - Tera Termによるネットワーク機器の状態確認・運用作業 - アラームの発報内容と時系列の確認 - 対向装置の状態および光受信レベルの確認 - 過去の類似障害や対応履歴の参照 - ケーブルルートや地理的条件を踏まえた障害箇所の推定 - 切り分け結果に基づく現地保守員への作業指示 ## 【課題・問題点】 大規模ネットワークでは、障害発生時に監視アラームだけで原因箇所を特定できるとは限らない。 例えば、光入力断のアラームが発生した場合でも、発報した装置自体に原因があるとは限らず、対向装置や装置間の伝送区間など、複数の可能性を考慮する必要がある。 また、ネットワークセンターから現地の設備状況を直接確認できないため、監視情報と物理的な設備構成を関連付け、現地で何が発生しているかを推定することが重要となる。 障害箇所の推定に時間を要すると、現地保守員への作業指示や復旧対応の開始にも影響するため、限られた情報から迅速に対応方針を判断することが求められる。 ## 【打ち手・使用した技術】 ### 複数の監視情報を組み合わせた障害解析 障害発生時には、アラームの発報時系列や関連装置の状態を確認し、対向装置の情報と比較する。 光入力断の場合には、光受信レベルや関連するアラームを確認し、障害が発生している可能性のある区間を絞り込む。 ### 過去の対応経験を活用した仮説構築 過去に経験した障害の発生状況や対応経過を記憶しており、現在の障害との共通点を見つけ、一次切り分けの判断材料として活用している。 過去の対応方法をそのまま適用するのではなく、現在のアラーム、装置状態、光受信レベルなどと照合し、類似事例との共通点や相違点を確認する。 過去の経験と現在の情報を関連付けることで、障害原因の候補を整理し、確認すべき事項や対応方針を検討している。 ### 物理的な設備情報を踏まえた状況推定 ケーブルルートや地理的条件なども考慮し、監視情報からは直接確認できない現地の状況を推定する。 論理的な監視情報と物理的な設備情報を組み合わせ、現地保守員への確認事項や作業指示の検討につなげている。 ## 【成果】 約1,200装置規模の通信ネットワークにおいて、障害検知から一次切り分け、現地保守員への作業指示まで継続して担当している。 光入力断などの障害に対し、アラーム情報、対向装置の状態、光受信レベル、過去の対応経験、ケーブルルートを組み合わせた障害箇所の推定を実践。 複数の情報源を関連付けて判断することで、現地で確認すべき事項を整理し、復旧対応につなげている。 # 技術的な対応内容② 障害復旧の推進・関係者調整 ## 【概要】 24時間365日の監視体制において、障害発生時の復旧対応と関係者への連絡・調整を担当。 台風などの影響で複数の障害が同時に発生する状況でも、影響範囲や緊急度を考慮して優先順位を判断し、限られた人員で複数案件を並行して対応している。 ## 【どのような業務・対応か】 - 障害状況と影響範囲の確認 - 障害対応の優先順位の判断 - 現地保守員への作業指示 - 関係部署との情報共有・対応調整 - 顧客への障害連絡・状況説明 - 現地からの情報を踏まえた対応方針の見直し - 復旧状況の確認と関係者への報告 ## 【課題・問題点】 各勤務帯では2名で監視業務を担当しており、障害発生時にも通常のネットワーク監視を継続する必要がある。 障害対応には、技術的な切り分け、現地保守員への指示、関係部署との調整、顧客連絡など複数の業務が含まれる。 特に台風時など、複数の障害が同時に発生する状況では、これらの業務を順番に処理すると、復旧対応や情報共有が停滞する可能性がある。 そのため、状況に応じて優先順位を判断し、限られた人員で対応を並行して進める必要がある。 ## 【打ち手・判断上の工夫】 ### 復旧を優先した意思決定 障害の影響範囲や緊急度を踏まえ、復旧に必要な対応を優先して実施する。 一方、初期段階の情報だけで対応方針を固定せず、追加アラームや現地からの報告など、新たな情報が得られた場合には対応方針を見直している。 ### 2名体制での柔軟な役割分担 勤務者2名で状況に応じて役割を分担し、障害切り分け、保守員対応、関係部署との調整、顧客連絡などを並行して進める。 各対応の緊急度や負荷を踏まえ、特定の担当者に業務が集中しないよう役割を調整している。 ### 関係者との認識共有 監視情報から推定した障害状況を整理し、現地保守員や関係部署に必要な情報を共有する。 現地から得られた情報も踏まえて判断を更新し、復旧に向けた対応を進めている。 ## 【成果】 台風時など複数障害が同時に発生する状況において、通常監視を継続しながら、障害切り分け、現地保守員への指示、関係部署との調整、顧客連絡を並行して担当した。 限られた人員の中で、状況に応じた優先順位の判断と柔軟な役割分担を実践している。 # 技術的な対応内容③ 現地状況の可視化と新任者OJT ## 【概要】 入社4年目から新任者1名のOJTを担当。 監視ツールの操作指導に加え、障害状況をイメージするための考え方や、過去事例を活用した一次切り分け、現地保守員への作業指示など、実際の障害対応を通じた育成を実施している。 ## 【どのような業務・対応か】 - 新任者への監視ツール操作指導 - アラーム確認と障害切り分けの実務指導 - 過去事例と現在の障害を関連付ける考え方の共有 - 設備構成や障害状況を手書きの図で可視化 - 新任者への現地保守員の作業指示業務の割り振り - 障害の緊急度や新任者の習熟度に応じた役割調整 ## 【課題・問題点】 ネットワークセンターでは現地の設備状況を直接確認できないため、複数の監視情報から現地で発生している状況をイメージする能力が求められる。 しかし、経験の浅い新任者にとっては、アラームの内容と実際の設備構成を関連付けることが難しい場合がある。 また、監視ツールの操作方法を習得するだけでは、障害発生時に何を確認し、どのような順序で対応を進めるべきかを判断することは難しい。 一方、各勤務帯は2名体制であり、OJT中も障害復旧や通常監視を継続する必要があるため、社内KPIと新任者の育成を両立することが課題となる。 ## 【打ち手・判断上の工夫】 ### 現地の状況を手書きの図で可視化 監視アラームや設備情報から推定した障害状況について、設備構成、障害が疑われる区間、対応の流れなどを手書きの図に整理して新任者へ共有する。 口頭説明だけでは伝わりにくい内容を図示することで、自身がイメージしている現地の状況や判断根拠を共有し、認識を合わせてから対応を進めている。 ### 過去事例と現在の障害の関連付け 過去の障害対応経験と現在のアラームや設備状況を関連付け、どの情報を確認するべきか、なぜその対応を優先するのかを説明する。 操作手順だけでなく、障害切り分けにおける仮説の立て方や判断の考え方を共有している。 ### 理解を実務経験につなげるOJT 対応方針を手書きの図などで共有したうえで、新任者に一次切り分けや現地保守員への作業指示を任せる機会を設けている。 単に説明を聞くだけでなく、自ら対応を実践することで、障害対応の経験を積んでもらうことを重視している。 ### 運用品質と育成の両立 障害の緊急度、社内KPI、新任者の習熟度や負担を考慮し、状況に応じて役割分担を変更する。 障害対応が集中する場合には、必要に応じて自身が対応を引き取り、復旧対応を優先している。 ## 【成果】 **入社4年目から新任者1名のOJTを担当し、障害切り分けや現地保守員への作業指示を実際に経験できる機会を設けた。** 手書きの図による障害状況の可視化と、過去事例を活用した判断根拠の共有を実施。 障害復旧を優先しながら、新任者が主体的に対応を経験できるよう、状況に応じた役割分担を行っている。 なお、育成期間の短縮や新任者の対応品質向上については、定量的な測定を行っていない。 # プロジェクト全体の成果・発揮した強み - **約1,200装置規模の通信ネットワークにおける24時間365日の監視・運用を担当** - **アラームの時系列、対向装置、光受信レベルを組み合わせた障害切り分けを実施** - **過去の障害対応経験と現在の状況を関連付け、障害原因の仮説構築に活用** - **ケーブルルートや地理的条件を考慮し、直接確認できない現地状況を推定** - **台風時などの障害輻輳に対し、2名体制で復旧対応と関係者調整を並行して推進** - **入社4年目から新任者1名のOJTを担当** - 手書きの図で設備構成や対応方針を共有し、新任者に現地保守員への作業指示などを任せる指導を実施 - 社内KPI、障害の緊急度、新任者の習熟度を考慮した柔軟な役割分担を実践 本業務では、監視アラームを確認して手順どおりに対応するだけでなく、複数の情報を関連付けて障害状況を推定し、必要な対応を判断することを重視している。 特に、過去の障害対応を記憶し、現在の障害との共通点を見つけて仮説を立てることを得意としている。 また、直接確認できない現地の状況を具体的にイメージし、その内容を手書きの図で可視化して他者に伝えることで、関係者との認識共有や新任者の育成につなげている。 障害復旧を最優先としながら、状況の変化に応じて判断や役割分担を見直し、限られた人員で複数の業務を並行して進めている。 **過去事例との関連付けによる仮説構築力、現地状況を推定する障害解析力、複雑な情報を可視化して共有する説明力、そして復旧対応と人材育成を両立する判断力が自身の強みである。**

# プロジェクト経験概要 KDDIグループ企業のネットワークセンターにおいて、Tera Termマクロ（TTL）を活用したネットワーク機器の設定投入自動化ツールを個人で開発し、実際の運用業務へ導入した。 回線の開通・解約に伴う設定投入作業について、作業時間の短縮とヒューマンエラー（HE）の防止を目的に、エッジスイッチ、集約スイッチ、POIスイッチに対応する設定投入マクロを開発。 従来はExcelに記載された設定コマンドをメモ帳へコピーし、装置・ポート・VLANなどの変数部分を手動で置換していた。 この作業を、Tera Termマクロの入力ボックスから必要な情報を一度入力する方式へ変更し、設定コマンドの準備・投入を効率化した。 また、複数回の確認コマンドや対話式のバックアウト機能を実装し、作業効率と安全性の両立を図った。 **ダブルチェックを含む2名分の合計で、1回線あたり約40分の工数削減を実現。** さらに、同じシフトのメンバー1名にマクロ作成・保守方法を指導し、自身以外にも開発・メンテナンスできる体制づくりに取り組んだ。 # チーム情報・担当範囲 - **所属：** ネットワークセンター - **開発体制：** 個人開発 - **役割：** 設計・開発・テスト・運用展開の主担当 - **担当工程：** 課題抽出、要件整理、設計、実装、テスト、運用展開、保守、技術指導 - **使用技術：** Tera Term、Tera Termマクロ（TTL）、ネットワーク機器CLI、VLAN - **対象装置：** エッジスイッチ、集約スイッチ、POIスイッチ - **対象業務：** 回線開通・解約に伴う設定投入作業 自身で現場の課題を抽出し、Tera Termマクロの設計・実装から運用展開まで一貫して担当した。 2024年前半に開通作業向けマクロの開発を開始し、2024年後半から2025年にかけて解約作業にも対象を拡大。 2025年前半以降は、同じシフトのメンバーへの技術指導にも取り組んだ。 # 開発・実装内容① 開通作業向けTera Termマクロの開発 ## 【概要】 2024年前半、回線開通時のネットワーク機器設定投入を効率化するため、Tera Termマクロを自作した。 自動化の初期段階では、操作ミスが発生した場合でも影響が比較的小さい開通作業から着手し、運用上のリスクを考慮しながら開発を進めた。 ## 【どのような機能の開発・実装か】 エッジスイッチ、集約スイッチ、POIスイッチへの設定投入を支援するマクロを開発した。 主な機能は以下のとおり。 - Tera Termマクロによる設定投入処理 - 入力ボックスを用いた装置・ポート・VLANなどの指定 - 入力した情報を使用した設定コマンドの準備 - ネットワーク機器への設定コマンド投入 - 設定確認用コマンドの実行 ## 【課題・問題点】 従来の設定投入作業では、Excelに記載されたコマンドをコピーしてメモ帳へ貼り付け、設定対象に応じて変数部分を手動で置換していた。 1回線の開通作業では複数のネットワーク機器への設定が必要となるため、装置ごとにコマンドを準備する必要があった。 特に、ポート番号やVLANなどの値を手動で置換する工程は入力ミスが発生しやすく、設定内容の確認にも工数を要していた。 また、設定投入作業にはダブルチェックが必要であり、作業者だけでなく確認者にも負担が発生していた。 ## 【打ち手・使用した技術】 ### ① 手動置換作業の削減 Tera Termマクロの入力ボックスを活用し、装置・ポート・VLANなどの情報を一度入力する方式を採用した。 入力した値を設定コマンドの準備に使用することで、Excelからコマンドをコピーして変数部分を繰り返し置換する作業を削減した。 ### ② 複数装置への対応 エッジスイッチ、集約スイッチ、POIスイッチへの設定投入を支援する機能を実装した。 回線開通に必要な複数装置の設定作業を、マクロによって効率的に進められる構成とした。 ### ③ リスクを考慮した段階的な導入 初期段階では、誤操作時の影響が比較的小さい開通作業を対象として開発した。 自動化対象を段階的に拡大することで、設定投入マクロの開発・運用経験を蓄積しながら改善を進めた。 ## 【成果】 開通作業向けのTera Termマクロを自作し、実際のネットワーク運用業務へ導入した。 コマンドのコピー・貼り付けや変数部分の手動置換を減らし、設定投入作業の効率化と入力ミスのリスク低減に貢献した。 # 開発・実装内容② 解約作業への拡張とヒューマンエラー対策 ## 【概要】 2024年後半から2025年にかけて、開通作業向けに開発したマクロの活用範囲を拡大し、回線解約時の設定投入にも対応した。 解約作業では、既存の通信サービスに影響する可能性を考慮し、確認コマンドとバックアウト機能を組み合わせた安全性重視の構成とした。 ## 【どのような機能の開発・実装か】 - 回線解約時の設定投入処理 - 装置・ポート・VLAN等の入力機能 - 複数回の確認コマンドの実行 - 操作者が選択できる対話式バックアウト機能 - 開通・解約それぞれの作業に対応したマクロの整備 ## 【課題・問題点】 ネットワーク機器への設定投入では、誤ったポートやVLANへの設定変更が通信サービスへ影響する可能性がある。 特に解約作業では、設定対象や作業内容を誤ることで、継続利用中のサービスへ影響するリスクを考慮する必要があった。 そのため、単に設定投入を自動化するだけではなく、作業対象の確認と、問題が発生した場合に設定を戻せる仕組みが重要だった。 ## 【打ち手・使用した技術】 ### ① 複数回の確認コマンド 設定投入処理に加えて、確認用コマンドを複数回実行する構成とした。 これにより、設定作業の途中や実施後に装置の状態を確認できるようにし、誤設定リスクの低減を図った。 ### ② 対話式バックアウト機能 Tera Termマクロ内に、操作者が判断してバックアウトを選択できる機能を実装した。 自動的に設定を戻す方式ではなく、操作者が状況を確認したうえでバックアウトを実行できる構成とした。 ### ③ 入力値の一元化 装置・ポート・VLANなどの情報を入力ボックスで一度指定し、設定コマンドの準備に使用する方式とした。 従来の手作業で発生していた変数部分の繰り返し置換を削減することで、入力ミスが生じやすい工程そのものを減らした。 ## 【成果】 開通作業に加えて解約作業にもマクロの適用範囲を拡大した。 複数回の確認コマンドと対話式バックアウト機能を実装し、設定投入作業の効率化だけでなく、安全性を考慮した運用を実現した。 **自身の入社以降、把握している範囲ではマクロ起因のヒューマンエラーは発生していない。** # 開発・実装内容③ 設定投入作業の効率化と工数削減 ## 【概要】 回線開通・解約に伴う設定投入作業について、コマンド準備、設定投入、確認作業の効率化を実施した。 ## 【課題・問題点】 従来は、Excelから設定コマンドをコピーし、メモ帳上でポート番号やVLANなどの変数部分を手入力で置換していた。 設定対象となる装置が複数あるため、コマンドの準備・確認・投入に時間を要していた。 さらに、ダブルチェックを実施する必要があり、作業者と確認者の双方に工数が発生していた。 ## 【打ち手・使用した技術】 - Tera Termマクロによる設定コマンドの準備・投入 - 入力ボックスによる設定値の一元入力 - 手動でのコピー・貼り付けや変数置換作業の削減 - 複数回の確認コマンドによる作業確認 - 必要に応じて選択できるバックアウト機能の実装 ## 【成果】 **1回線あたり約40分の工数削減を実現した。** この数値は、従来の手作業と比較した、ダブルチェックを含む2名分の合計削減工数である。 開通・解約を合わせて週約10回線の作業を対象としており、同規模の処理が継続した場合、以下の削減効果が見込まれる。 - **1回線あたり：約40分削減** - **週10回線の場合：約6.7時間分の削減** - **年間52週換算：約347時間分の削減** ※週間・年間の数値は、週10回線すべてにマクロを適用した場合の試算であり、年間の実測値ではない。 作業時間の短縮に加え、変数部分の手動置換を削減することで、入力ミスが発生しやすい工程を減らした。 # 開発・実装内容④ マクロ開発・保守技術のチーム内共有 ## 【概要】 2025年前半以降、自身が開発したTera Termマクロの作成・保守方法を、同じシフトのメンバー1名に指導した。 ## 【課題・問題点】 マクロの開発・保守を自身だけが担当する状態では、修正や機能追加が必要になった際に対応できる担当者が限られてしまう。 そのため、マクロを継続して利用・改善できるよう、開発・保守方法を他メンバーへ共有する必要があった。 ## 【打ち手・工夫】 - Tera Termマクロの作成方法を指導 - 既存マクロの処理内容や構成を共有 - マクロの修正・メンテナンス方法を指導 - 自身以外にも開発・保守できるメンバーを増やす取り組みを実施 また、自身は先輩社員から障害対応に関する知識や技術を学ぶ一方、得意分野であるマクロ開発については指導する立場となり、相互に知識を共有した。 ## 【成果】 **同じシフトのメンバー1名に対して、Tera Termマクロの作成・保守方法を指導した。** マクロ開発・保守に関するノウハウを共有し、特定の担当者に依存しない運用体制づくりに貢献した。 # 技術選定・設計上の工夫 ## 【Tera Termマクロを採用した理由】 既存のネットワーク運用業務で使用しているTera Termを活用し、設定投入作業の自動化を実現できる点を重視した。 新たな専用システムを導入するのではなく、既存の運用環境で利用可能なTera Termマクロを自作することで、現場業務に適したツールを構築した。 ## 【入力ミスを発生させにくい構成】 従来のExcelからメモ帳へのコピー・貼り付けと、変数部分の手動置換を削減した。 装置・ポート・VLANなどの設定値を入力ボックスから一度指定する構成とし、同じ値を繰り返し手入力する工程を減らした。 ## 【安全性を考慮した設定投入】 複数回の確認コマンドと対話式バックアウト機能を実装した。 単に設定投入を自動化するのではなく、作業確認と問題発生時の復旧手段を考慮した設計とした。 ## 【段階的な開発・適用範囲の拡大】 2024年前半は、操作ミスが発生しても影響が比較的小さい開通作業から開発を開始した。 その後、2024年後半から2025年にかけて解約作業にも対応し、リスクを考慮しながら自動化対象を拡大した。 # プロジェクト全体の成果・発揮した強み - **Tera Termマクロ（TTL）を個人で設計・開発し、実際のネットワーク運用業務へ展開** - **エッジスイッチ、集約スイッチ、POIスイッチに対応** - **開通・解約に伴う設定投入作業を自動化** - **ダブルチェックを含む2名分の合計で、1回線あたり約40分の工数削減** - **週約10回線の作業規模に対し、約6.7時間/週の削減効果を見込める仕組みを構築** - **複数回の確認コマンドと対話式バックアウト機能を実装** - **把握している範囲で、入社後のマクロ起因HEはゼロ** - **同じシフトのメンバー1名へマクロの作成・保守方法を指導** - **2024年から2025年にかけて、開通作業から解約作業へ段階的に適用範囲を拡大** 本プロジェクトでは、単に手作業を自動化するだけでなく、ヒューマンエラーが発生しやすい工程を分析し、入力方法そのものを見直した。 また、ネットワーク機器への設定投入は誤操作による通信影響のリスクがあるため、段階的な導入、複数回の確認コマンド、対話式バックアウト機能など、安全性を考慮した設計を重視した。 さらに、自身が開発したマクロの作成・保守方法を他メンバーへ共有し、チーム全体で継続的に改善できる体制づくりにも取り組んだ。 **現場の課題分析からツール設計・開発、運用展開、定量的な工数削減、ヒューマンエラー対策、技術移転まで一貫して実施できることが自身の強みである。**