FortiGate Automation Stitch の設定手順と運用設計のポイント

URLをコピーしました！

はじめに

FortiGate の運用では、定期的なコンフィグバックアップ、リソースしきい値の超過検知、管理者のログイン失敗といったイベントに対して、手動で確認や対応を行っている環境が少なくありません。Automation Stitch は、こうした「特定の条件が成立したときに、決められた処理を実行する」流れを FortiGate 自身に持たせる機能です。

本記事では、Automation Stitch の構成要素と設定手順に加えて、Security Fabric や multi-VDOM 環境での適用範囲、実運用に入れる前に把握しておきたい制約を整理します。

この記事でわかること

Automation Stitch の構成要素（Trigger / Action / Stitch）と GUI・CLI の対応
Security Fabric 環境や multi-VDOM 環境での作成場所と同期の考え方
トリガー種別の選び方と、スケジュール指定における粒度の制約
CLI Script アクションの設定手順、必要な権限、実行結果の扱い
定期実行・しきい値検知・イベント通知の構成例と、運用設計上の落とし穴

結論を先に述べると、Automation Stitch は Trigger（契機）と Action（処理）の 2 要素で構成され、両者を Stitch として紐づけることで動作します。Security Fabric を構成している場合、Stitch を作成できるのは root の FortiGate に限られ、multi-VDOM 環境では Global 配下のメニューに表示されます。アクションの中では CLI Script が最も自由度が高い一方、実行に必要な権限や結果の扱いに固有の注意点があります。

Automation Stitch の構成要素と適用範囲

このセクションでは、Automation Stitch を構成する 3 つのオブジェクトの関係と、Security Fabric・multi-VDOM 環境における適用範囲を整理します。設定手順に入る前に、どの装置のどの階層で設定するのかを押さえておくと、設定画面が見つからないといった手戻りを避けられます。

Trigger と Action、Stitch の関係

Automation Stitch は、契機となる Trigger と、それに応じて実行される Action の組み合わせで構成されます。

参考: Automation stitches（FortiOS Administration Guide）
“An automation stitch consists of two parts: the trigger and the actions.”
（Automation Stitch は、トリガーとアクションという 2 つの要素で構成される）
https://docs.fortinet.com/document/fortigate/7.6.6/administration-guide/139441/automation-stitches

GUI では Security Fabric > Automation に、Stitch / Trigger / Action の 3 つのタブが用意されています。既定の表示は Stitch タブで、各 Stitch がどの Trigger とどの Action を使っているかが一覧表示されます。Trigger と Action は、それぞれのタブから個別に作成・編集できます。

CLI では、以下の 3 つのコンフィグ階層が対応します。

オブジェクト	CLI の階層	役割
Trigger	`config system automation-trigger`	契機となる条件・イベントを定義
Action	`config system automation-action`	実行する処理を定義
Stitch	`config system automation-stitch`	Trigger と Action を紐づけ

Stitch 側では、使用する Trigger を指定したうえで、実行する Action を config actions の配下に順番に登録します。以下は公式管理ガイドに示されている設定例の構造です。

config system automation-stitch
    edit "<スティッチ名>"
        set description "<説明>"
        set trigger "<トリガー名>"
        config actions
            edit 1
                set action "<アクション名>"
                set required enable
            next
        end
    next
end

1 つの Stitch に複数の Action を登録でき、実行順序や遅延の挿入も設定できます。この点は運用設計に関わるため、後のセクションで扱います。

Security Fabric 環境での作成場所と同期

Security Fabric を構成している環境では、Automation Stitch を作成できるのは root の FortiGate に限られます。ダウンストリームの FortiGate 側で個別に作成しようとして設定できず、原因を探すことになりやすい箇所です。

作成した設定を Fabric 内で同期するかどうかは、以下の設定で制御します。

config automation setting
    set fabric-sync {enable | disable}
end

有効にすると自動化の設定が Security Fabric 内で同期され、無効にすると個々の FortiGate にのみ適用される形になります。なお、この設定の既定値は公式 CLI リファレンスで確認できなかったため、変更の前に show full-configuration などで現行値を確認することを推奨します。

また、Automation Stitch は Security Fabric に参加していない単体の FortiGate でも利用できます。Security Fabric のメニュー配下にあるため Fabric 構成が前提と受け取られやすいものの、単体運用の装置で定期実行や通知を組む用途にもそのまま使えます。

multi-VDOM 環境でのメニュー位置

multi-VDOM モードが有効な環境では、Automation のメニューは Global 配下に表示され、個々の VDOM の管理画面には現れません。VDOM 管理者としてログインした状態では設定項目が見つからないため、Global にアクセスできる管理者アカウントで操作する必要があります。

Fortinet Community にも、multi-VDOM 環境で自動コンフィグバックアップを構成する手順として、Global VDOM 側で CLI Script のアクションを作成する例が公開されています。VDOM ごとに異なる処理を実行したい場合は、CLI Script の中で対象 VDOM を切り替える形になります。

あわせて、外部との通信を伴うアクション（メール送信や外部サーバーへのバックアップ送信など）は、管理 VDOM を経由して発信される点に注意が必要です。通信が到達しない場合、Stitch 側ではなく管理 VDOM 側の経路やポリシーが原因となっているケースが考えられます。

トリガーの種類と選び方

Automation Stitch の設計は、どの契機で動かすかを決めるところから始まります。このセクションでは、トリガーの分類と、用途に応じた選び方を整理します。

静的トリガーと動的トリガー

FortiOS のトリガーは、静的トリガーと動的トリガーの 2 種類に分かれます。

参考: Triggers（FortiOS Administration Guide）
“Static automation triggers are included in FortiOS by default.”
（静的な自動化トリガーは、FortiOS に既定で組み込まれている）
https://docs.fortinet.com/document/fortigate/7.6.3/administration-guide/43081/triggers

静的トリガーは FortiOS に最初から用意されており、名前・説明と設定項目 1 つのみで成立します。編集はできますが削除はできません。Configuration Change や Conserve Mode のように、条件が固定されているものが該当します。

動的トリガーは複数の設定を必要とするもので、Trigger タブの Create New から作成します。FortiOS Event Log トリガーやスケジュールトリガーがこれにあたります。GUI の Create New に表示されるのは動的トリガーのみであるため、静的トリガーを使いたい場合は作成せず、Trigger タブの一覧または Stitch 作成画面から既存のものを選択します。作成ボタンを押しても目的のトリガーが見つからない、という状況はこの仕様によるものです。

用途別のトリガーの選び方

実務での使い分けは、おおむね以下の 4 系統に整理できます。

契機の種類	代表的なトリガー	向いている用途
システム状態の変化	Conserve Mode、Configuration Change、HA Failover	リソース逼迫や構成変更の検知と通知
ログの発生	FortiOS Event Log	特定のイベント ID に紐づけた細かい条件設定
時刻・周期	Schedule	定期バックアップ、定型作業の自動実行
外部システム連携	Incoming Webhook、FortiAnalyzer Event Handler	外部の検知基盤やプレイブックからの起動

利用できるトリガーの種類は FortiOS のバージョンによって差があります。実際に設定する際は、公式管理ガイドの Triggers ページとあわせて、対象機の Security Fabric > Automation > Trigger タブに表示される一覧を確認することを推奨します。

FortiOS Event Log トリガーの設定

汎用性が高いのが FortiOS Event Log トリガーです。特定のイベントログ ID の発生を契機にできるため、静的トリガーでは拾えない事象にも対応できます。

設定上のポイントは 3 点です。第 1 に、1 つのトリガーに設定できるログ ID は最大 16 個です。第 2 に、フィールドフィルターを追加した場合、設定したフィルターがすべて一致したときにのみ Stitch が起動します。第 3 に、Log & Report > System Events のログ一覧から対象ログを右クリックしてトリガーを作成するショートカットが用意されており、この方法ではイベントが自動で設定された状態で作成画面が開きます。ログ ID の特定に迷う場合は、この手順が確実です。

GUI 上のイベント名は FortiOS Log Message Reference の Message Meaning に対応しており、項目にカーソルを合わせるとイベント ID とログ名が表示されます。公式管理ガイドでは、GUI の Admin login successful がログ ID 32001（LOG_ID_ADMIN_LOGIN_SUCC）に対応する例が示されています。

CLI では以下の形式になります。

config system automation-trigger
    edit "<トリガー名>"
        set event-type event-log
        set logid <ログ ID>
        config fields
            edit 1
                set name "<フィールド名>"
                set value "<値>"
            next
        end
    next
end

参考: FortiOS event log trigger（FortiOS Administration Guide）
https://docs.fortinet.com/document/fortigate/8.0.0/administration-guide/950487/fortios-event-log-trigger

公式管理ガイドでは、ファームウェアの更新完了を示すイベントログからトリガーを作成する例も示されています。意図しないタイミングでのバージョン変更を把握したい場合は、この仕組みで検知できます。FortiGate の自動アップグレードの仕様そのものについては、関連記事『FortiGate 強制自動アップグレードの仕様と無効化手順』で解説しています。

スケジュールトリガーと粒度の制約

定期実行を組む場合はスケジュールトリガーを使います。CLI での設定形式は以下のとおりです。

config system automation-trigger
    edit "<トリガー名>"
        set trigger-type scheduled
        set trigger-frequency weekly
        set trigger-weekday sunday
        set trigger-hour 23
        set trigger-minute 0
    next
end

ここで把握しておきたいのが、スケジューラの指定粒度に制約がある点です。Fortinet Community の技術記事には、月次実行において日付（何日）の指定はできるものの、「毎月第 2 火曜」のような曜日ベースの指定はできない旨が記載されています。パッチ適用日などを曜日基準で運用している環境では、この制約が設計に影響します。

参考: Technical Tip: Using Automation Stitch to schedule restart/reboot FortiGate（Fortinet Community）
https://community.fortinet.com/fortigate-3/technical-tip-using-automation-stitch-to-schedule-restart-reboot-fortigate-94305

CLI Script アクションの設定手順

アクションの中で最も自由度が高いのが CLI Script です。FortiGate 上で実行できるコマンドをそのまま登録できるため、通知だけでなく設定変更や情報採取まで組み込めます。

GUI での設定手順

Security Fabric > Automation を開き、Action タブを選択します
Create New をクリックし、CLI Script を選択します
名前を入力し、Script の欄に実行するコマンドを記述します
実行に使用する管理者プロファイル（accprofile）を指定します
OK で保存し、Stitch タブで作成済みのトリガーと組み合わせます

CLI での設定

CLI では config system automation-action にアクションを定義します。

config system automation-action
    edit "<アクション名>"
        set action-type cli-script
        set script "<実行するコマンド>"
        set accprofile "super_admin"
    next
end

参考: config system automation-action（FortiOS CLI Reference）
https://docs.fortinet.com/document/fortigate/7.2.0/cli-reference/149620/config-system-automation-action

accprofile は、スクリプトを実行する際の管理者権限プロファイルを指定するパラメータです。実行するコマンドに対して権限が不足していると、Stitch は起動しても処理が完了しません。診断系コマンドやシステム操作を含む場合は super_admin 相当のプロファイルを指定するのが確実です。逆に言えば、権限を絞ったプロファイルを指定することで、スクリプトが実行できる範囲を限定する設計も可能です。

実行結果の扱いに関するパラメータ

CLI Script アクションには、実行結果の取り扱いに関わるパラメータが用意されています。公式 CLI リファレンスで確認できる主なものは以下のとおりです。

パラメータ	役割
`output-size`	スクリプトの実行結果として保持する出力サイズ
`timeout`	スクリプトの実行を打ち切るまでの時間
`minimum-interval`	同じアクションが連続実行される間隔の下限
`execute-security-fabric`	Security Fabric のメンバー上で実行するかどうか

出力を伴うコマンド（diagnose 系など）を登録する場合、output-size と timeout の設定が結果の取得可否に影響します。出力量が多いコマンドでは、既定のままでは結果が途中で切れる可能性があるため、必要に応じた調整を検討します。これらの既定値と設定可能な範囲は公式 CLI リファレンスで確認できなかったため、実機で set output-size ? などにより確認することを推奨します。

なお、CLI Script の実行結果は %%results%% という変数でメールアクションなどに引き渡せます。「情報を採取して、その内容をメールで受け取る」という構成は、この変数を使って実現します。具体的な組み立ては次のセクションの構成例で扱います。

minimum-interval は、短時間に同じイベントが連続発生した際の多重実行を抑える役割を持ちます。運用設計に直結する項目のため、後のセクションであらためて整理します。

実務で使える構成例

ここまでの要素を組み合わせた構成例を 3 つ紹介します。いずれも公式ドキュメントまたは Fortinet Community の技術記事に基づく内容です。実際に適用する際は、対象機のバージョンで各コマンドが受け付けられるかを確認することを推奨します。

構成例 1: スケジュール実行によるコンフィグバックアップ

外部サーバーへ定期的にコンフィグを退避する構成です。スケジュールトリガーと CLI Script の組み合わせで実現します。

config system automation-trigger
    edit "daily_backup_trigger"
        set trigger-type scheduled
        set trigger-frequency daily
        set trigger-hour 2
        set trigger-minute 0
    next
end

config system automation-action
    edit "daily_backup_action"
        set action-type cli-script
        set script "execute backup config ftp <ファイル名> <サーバー IP> <ユーザー名> <パスワード>"
        set accprofile "super_admin"
    next
end

config system automation-stitch
    edit "daily_backup"
        set status enable
        set trigger "daily_backup_trigger"
        config actions
            edit 1
                set action "daily_backup_action"
                set required enable
            next
        end
    next
end

この構成には、把握しておきたい注意点が 3 点あります。

1 点目は accprofile の指定です。 Fortinet Community の技術記事では、super_admin 以外のプロファイルを指定した場合、送信されるコンフィグファイルが不完全になる旨が明記されています。

参考: Technical Tip: How to send automated backups of the configuration from a FortiGate with an automation stitch（Fortinet Community）
“Without super_admin, the full config file will not send via TFTP/FTP or SFTP server”
（super_admin でない場合、完全なコンフィグファイルは TFTP/FTP または SFTP サーバーへ送信されない）
https://community.fortinet.com/fortigate-3/technical-tip-how-to-send-automated-backups-of-the-configuration-from-a-fortigate-with-an-automation-stitch-using-tftp-ftp-or-sftp-server-and-a-recommendation-for-configuring-a-linux-machine-99783

同記事によれば、権限が不足している場合は super_admin アカウントの定義が欠落するほか、ファイアウォールポリシーやセキュリティプロファイルが含まれない可能性があります。バックアップは取得できているように見えて中身が欠けているという状態は、リストアが必要になった局面まで気づきにくいため、設定時に必ず確認したい項目です。

2 点目は、ファイル名に使う変数の展開タイミングです。 ファイル名に日付やホスト名の変数を埋め込むと、世代管理がしやすくなります。ただし同記事には、CLI で execute backup config を手動実行した場合、変数は展開されず文字列のまま扱われる旨が記載されています。動作確認は Stitch のテスト実行（Stitch タブで右クリックし Test Automation Stitch）で行う必要があります。使用できる変数の正確な表記はバージョンによって差があるため、適用前に公式 KB での確認を推奨します。

3 点目は、複数台構成でのファイル名の重複です。 Fortinet Community の別の技術記事では、Security Fabric 配下の複数の装置で同じ Stitch を実行した結果、同一ファイル名が生成され、FTP サーバー上でファイルが上書きされる事象が扱われています。ホスト名などの装置固有の値をファイル名に含めることで回避できます。あわせて、ファイル名に時刻を含める場合、Windows ベースのサーバーではコロン（:）を含むファイル名が使えない点にも注意が必要です。

構成例 2: Conserve Mode 検知時の情報採取とメール通知

メモリ逼迫で Conserve Mode へ移行した際に、原因調査に使う情報を自動採取し、結果をメールで受け取る構成です。公式管理ガイドに設定例が掲載されています。

config system automation-action
    edit "high_memory_debug"
        set action-type cli-script
        set script "diagnose sys top 5 20 3
diagnose sys session full-stat
get system performance status
diagnose hardware sysinfo shm
diagnose hardware sysinfo memory"
        set output-size 10
        set timeout 0
        set accprofile "super_admin"
    next
    edit "auto_high_memory_email"
        set action-type email
        set email-to "<宛先アドレス>"
        set email-subject "CSF stitch alert: high_memory"
        set message "%%results%%"
    next
end

config system automation-stitch
    edit "auto_high_memory"
        set trigger "Conserve Mode"
        config actions
            edit 1
                set action "high_memory_debug"
                set required enable
            next
            edit 2
                set action "auto_high_memory_email"
                set required enable
            next
        end
    next
end

参考: Execute a CLI script based on memory and CPU thresholds（FortiOS Administration Guide）
https://docs.fortinet.com/document/fortigate/7.6.1/administration-guide/702937/execute-a-cli-script-based-on-memory-and-cpu-thresholds

ポイントは 3 点です。第 1 に、トリガーには静的トリガーの Conserve Mode をそのまま指定します。第 2 に、CLI Script では複数のコマンドを改行区切りで記述でき、結果は %%results%% でメールアクションへ引き渡されます。第 3 に、CLI Script の実行結果をメールで受け取る構成のため、Stitch のアクション実行順序は Sequential とし、CLI Script を先に配置する必要があります。

Conserve Mode へ移行するしきい値は、以下のグローバル設定で調整できます。

config system global
    set cpu-use-threshold <percent>
    set memory-use-threshold-extreme <percent>
    set memory-use-threshold-green <percent>
    set memory-use-threshold-red <percent>
end

この構成は情報採取と通知が目的であり、Conserve Mode の原因そのものを解消するものではありません。特定のプロセスに起因してメモリが逼迫している場合は、原因側への対処が必要です。node プロセスのメモリ増大が疑われるケースについては、関連記事『FortiGate node メモリ増大｜Bug ID 1227167 の回避策』で、公式の回避策と選定基準を解説しています。

構成例 3: 管理者ログイン失敗の通知

管理者アカウントへのログイン失敗を検知して通知する構成です。FortiOS Event Log トリガーを使用します。

config system automation-trigger
    edit "admin_login_failed"
        set event-type event-log
        set logid 32002
    next
end

config system automation-action
    edit "admin_login_failed_email"
        set action-type email
        set email-to "<宛先アドレス>"
        set email-subject "FortiGate: admin login failed"
        set message "%%log%%"
    next
end

ログ ID 32002 は Admin login failed に対応します。メールアクションの本文に %%log%% を指定すると、契機となったログの内容がそのまま本文に含まれます。送信元 IP アドレスやユーザー名を含むログが届くため、通知を見た時点で一次判断ができます。

この構成で注意したいのが、多重通知です。総当たり的なログイン試行を受けた場合、短時間に大量のメールが送信される可能性があります。minimum-interval による抑制、またはフィールドフィルターによる対象の絞り込みを併用する設計を推奨します。抑制の考え方は次のセクションで整理します。

運用設計の落とし穴とテスト方法

Stitch は設定自体は短時間で終わりますが、本番環境で意図どおりに動作させるには、実行順序・多重発火・適用先といった観点を押さえておく必要があります。このセクションでは、設計時に確認したい項目とテスト方法を整理します。

アクションの実行順序と遅延

Stitch には複数の Action を登録でき、実行方式として Sequential（順次）と Parallel（並列）を選択できます。Sequential を選んだ場合に限り、アクションの間に遅延を挿入でき、遅延時間は最大 3600 秒（1 時間）です。

構成例 2 のように、CLI Script の実行結果を %%results%% でメールへ引き渡す構成では、CLI Script が完了してからメールが送信される順序である必要があります。Parallel を選ぶと結果が揃わないまま送信される可能性があるため、結果の受け渡しを伴う構成では Sequential を選択します。

なお、公式ドキュメントの設定例では、各アクションに set required enable が指定されています。この指定の詳細な挙動は公式リファレンスで確認できなかったため、適用前に検証環境での動作確認を推奨します。

多重発火の抑制

ログを契機とする Stitch では、短時間に同じイベントが繰り返し発生した場合、そのたびにアクションが実行されます。構成例 3 のような通知構成では、大量のメールが送信される状況が起こり得ます。

これを抑えるのが minimum-interval です。同じアクションが連続して実行される間隔の下限を設定でき、指定した時間内の再実行を抑制します。

config system automation-action
    edit "<アクション名>"
        set minimum-interval <秒>
    next
end

通知系のアクションでは、フィールドフィルターによる対象の絞り込みと minimum-interval の設定をセットで検討することを推奨します。通知が多すぎて確認されなくなる状態は、通知が届かない状態と実質的に変わらないためです。

同時実行数の上限

同時に実行できる Stitch の数には上限があります。既定値は 128 で、32〜256 の範囲で変更できます。

config automation setting
    set max-concurrent-stitches <整数>
end

Stitch を多数定義している環境や、短時間に多くのイベントが発生する環境では、この上限が実行漏れの原因になる可能性があります。動作しない Stitch がある場合の確認項目のひとつです。

HA 構成での考慮点

Stitch には適用先を示す情報が含まれており、公式管理ガイドの診断コマンド出力では、destinations: all のようにすべての装置を対象とする指定と、HA クラスタ名を指定した形の両方が確認できます。

CLI Script アクションは実行された装置上で動作するため、両系で同じ処理を実行したい場合は、適用先の設計が必要になります。Fortinet Community の技術記事には、Automation Stitch で HA クラスタを対象に再起動を行う場合、追加の設定が必要である旨が記載されています。HA 構成に導入する際は、片系のみで動作する構成になっていないかを設計段階で確認することを推奨します。

テストと動作確認

作成した Stitch は、実際のイベントを待たずにテスト実行できます。GUI では Security Fabric > Automation の Stitch タブで対象を右クリックし、Test Automation Stitch を選択します。CLI では以下のコマンドを使用します。

diagnose automation test <スティッチ名>

構成例 1 で触れたとおり、ファイル名の変数はこのテスト実行または実際の発火でのみ展開されます。CLI で直接コマンドを実行しても変数は文字列のまま扱われるため、動作確認は必ず Stitch 単位で行うことを推奨します。

期待どおりに動作しない場合は、以下の診断コマンドで状態を確認できます。

コマンド	確認できる内容
`diagnose test application autod 1`	ログダンプの有効・無効の切り替え
`diagnose test application autod 2`	有効な Stitch の設定内容（トリガー、アクション、適用先）
`diagnose test application autod 3`	Stitch ごとの実行統計（発火回数、最終実行日時）

参考: Diagnosing automation stitches（FortiOS Administration Guide）
https://docs.fortinet.com/document/fortigate/7.6.0/administration-guide/921599/diagnosing-automation-stitches

引数 2 の出力では、Stitch が有効化されているか、トリガーとアクションの紐づけが意図どおりかを確認できます。引数 3 の出力では発火回数が確認できるため、「トリガーが発火していないのか、アクションが失敗しているのか」の切り分けに使えます。発火回数が増えていなければトリガー側、増えているのに結果が得られていなければアクション側という判断になります。

なお、Fortinet Community の技術記事では、Stitch が動作しない場合の対処として autod（automation daemon）の再起動が挙げられています。

参考: Technical Tip: Diagnose automation stiches（Fortinet Community）
“a possible solution is to perform a restart of automation daemon (autod)”
（対処のひとつとして、automation daemon（autod）の再起動が挙げられる）
https://community.fortinet.com/t5/FortiGate/Technical-Tip-Diagnose-automation-stiches/ta-p/190930

再起動の前後でプロセス ID を比較することで、再起動が完了したかを確認できます。

まとめ

Automation Stitch は、Trigger と Action を組み合わせて FortiGate 上の定型作業や検知後の対応を自動化する機能です。設定自体は短時間で完了しますが、作成できる装置の制限、権限による動作の違い、スケジュール指定の粒度といった制約を把握しておくことで、想定と異なる動作を避けられます。

Stitch は Trigger と Action の 2 要素で構成
Security Fabric 環境では root の FortiGate でのみ作成可能
multi-VDOM 環境では Global 配下にメニューが表示される
CLI Script の accprofile が不足するとバックアップ内容が欠落
月次スケジュールで曜日ベースの指定はできない
通知系は minimum-interval とフィルターで多重発火を抑制
動作確認は Stitch のテスト実行と autod の診断コマンドで実施

以上、最後までお読みいただきありがとうございました。

よかったらシェアしてね！

URLをコピーしました！

Cisco FMC 脆弱性 2 件が KEV 登録｜期限 3 日と対処手順

この記事を書いた人

とも

関西を拠点に活動する、現役インフラエンジニア。経験20年超。

大手通信キャリアにて、中〜大規模インフラ（ネットワーク・サーバ・クラウド・セキュリティ）の設計・構築およびプロジェクトマネジメントに従事。現場で直面した技術課題への対処や、最新の脆弱性情報への実務対応を、一次情報として発信しています。

保有資格
CCIE Lifetime Emeritus（取得から20年以上）／ VCAP-DCA ／ Azure Solutions Architect Expert

▶ 運営者プロフィール（詳細）

2026年7月
月	火	水	木	金	土	日
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31