この記事のTL;DR
- 保育園の連絡帳アプリで、毎朝AIが自動で下書きしてくれる仕組みを作りました
- ただしAIが書くのはあくまで下書きだけ。送信は人間がやります
- 「毎日同じこと書く定型文おじさん
」にならないよう、直近7日の連絡帳をMemoryに保存して重複文を回避しています
1. 我が家の朝は、控えめに言って戦場
である
突然ですが、保育園に子どもを通わせている皆さん。あの ”連絡帳” ってありますよね。
スマホでポチポチ「家庭からの連絡」を入力して送信する、アレです。文章にすると数十秒の、なんともない作業です……平常時なら。
でも、朝の我が家に平常時は存在しません。実際のタイムラインをご覧ください。
6:50 起床。すでに時間がない
7:05 子「ヤダ」 妻「早くして」 子「ヤダ」
7:15 味噌汁が床に着地（不可抗力）
7:20 妻の怒りゲージMAX
7:25 子号泣
7:30 妻「ねぇ、パパ連絡帳まだ書いてないの！？(怒)」 私「えっ…」
7:31 詰み…
この状況下で
「昨晩はぐっすり眠り、朝はご飯を完食しました。今日も元気いっぱいです
」
などと穏やかな育児エッセイを書ける人間がいたら、私は表彰したい。
私には無理でした。なので毎朝「元気です。よろしくお願いします。」とだけ書いて送信する日々です。
「元気です。よろしくお願いします。」
「元気です。よろしくお願いします。」
「元気です。よろしくお願いします。」
……このままでは 「定型文おじさん」 と呼ばれてしまう。そこで思ったわけです。
AIエージェントにやらせよう！
2. 作ったもの：AIが下書き、人間が承認
結論はシンプルです。
連絡帳の下書きはAIに書かせる。人間は内容を確認して「送信」を押すだけ。
ポイントは 「全自動にしない」 こと。
連絡帳は先生とのコミュニケーションであり、子どもの安全にも関わる情報が乗ります。もしAIが勝手に
「昨晩39℃の発熱がありました」
なんて創作して勝手に送信したら、それはもう事故です。なので役割分担はこうしました。
| 工程 | 担当 | 理由 |
|---|---|---|
| 毎朝の起動 | AWS（EventBridge） | 人間は忘れる |
| 文章生成 | エージェント（AgentCore Harness / LLM） | イレギュラー時は必ず人間が書く |
| ログイン・入力・下書き保存 | Lambda（Playwright） | 朝は時間がない＆送信しないことをコードで担保 |
| 内容の確認 | 人間 | ここは人間の責任（重要） |
| 送信 | 人間 | 事故防止のラストゲート |
大事なことなのでもう一度。送信ボタンは私（人間）が押します。 ここだけは絶対にAIに委ねません。
3. アーキテクチャ：全体像
頭脳（Harness）と手足（Lambda）を分ける
今回のキモは、「考える役」と「操作する役」をきっぱり分けたことです。
-
頭脳＝AgentCore Harness（LLM）
Skill（実行ガイド）と Memory（直近7日の履歴）をもとに、その日の文面を考える。そして「下書きして」というツールを 1回呼ぶだけ。 -
手足＝Lambda（Playwright）
渡された文面で、連絡帳アプリに毎回まったく同じ手順でログイン → 入力 → 下書き保存する。コードで書いた決定的な処理。
この2つを AgentCore Gateway がつなぎます。Gateway は「Lambda関数を、エージェントから呼べる”ツール（MCP）”に変換する」レイヤーですね。
今回の Gateway 名は children-gateway。そこが公開するツールが save_child_draft(message) ——Harness からはこの1個のツールに見えていて、その実体が Lambda、という構図です。
なぜ AgentCore の「ブラウザツール」を使わなかったのか
AgentCore には標準でマネージドなブラウザツールがあり、これだけでもWeb操作はできます。でも今回はあえて使いませんでした。理由は 「決定性」と「安全性」 です。
ブラウザツールは AIがその場で判断して操作します。つまり毎回まったく同じ動きになる保証がなく、最悪「送信ボタンを押す」という判断をされたら一発アウト。連絡帳は誤送信が許されないので、ここはAIに委ねたくありませんでした。
そこでブラウザ操作は Playwright で手順を固定した Lambda にして、「下書き保存だけ押す／送信ボタンには絶対に触らない」をプログラムで保証しました。
AIが決めるのは「何を書くか」だけ。
「どう操作するか」は決定的なコードが担当。
——この線引きが、そのまま安心につながっています。
| 役割 | 担当 | 性質 |
|---|---|---|
| いつ動かすか | EventBridge | 決定的 |
| 何を書くか（文面・重複回避） | Harness（LLM）＋Memory＋Skill | 賢い／非決定的 |
| どう操作するか（ログイン〜下書き保存） | Lambda（Playwright） | 決定的・送信しない |
| 認証情報 | Secrets Manager | 隔離 |
| 最終確認・送信 | 人間 | ラストゲート |
連絡帳アプリ側の予期せぬ改修で想定と異なる動きをする可能性は否定できません
エージェントの「指示書」=Skill の全文
📄 SKILL.md の全文を見る
---
name: renrakucho
description: 連絡帳に書く、当たり障りのない自然な日本語コメントを作るためのガイド。連絡帳の文面を作るときに使う。文面を作ったら children-gateway ツールに渡す。
---
# 連絡帳コメントの書き方
## このスキルの役割
あなた（エージェント）の仕事は、**その日の連絡帳コメントの文面を考えること**と、それを `children-gateway` ツールに渡すことだけ。
**あなたはブラウザ操作をしない。**
## 自律実行（確認・質問はしない）
このスキルは EventBridge による日次自動起動（無人実行）で動作する。実行中に人間はその場におらず、エージェントが質問しても誰も答えられない。
したがって、文面の作成・決定から `children-gateway` ツールでの**下書き保存まで、ユーザーへの確認・質問を一切しない**。情報が不足している・判断に迷う場面でも、質問で処理を止めず、自分で無難な内容を判断して下書き保存まで完了する。
## 文章ガイド（当たり障りのないコメント）
- 1〜2文。丁寧でポジティブ。保護者から保育士への連絡帳コメント。
- 家庭での様子（睡眠・食事・機嫌・体調など）の軽い報告＋「今日もよろしくお願いします」的な締め。
- **時間的コンテキスト**: この文章は**朝に書かれ、先生が日中（その日のこれから）に読む**もの。「今日これからお世話になる」タイミングであることを意識した表現にする。「今日もよろしくお願いします」「引き続きよろしくお願いします」のような、これから始まる一日に向けた前向きな締めが適切。
- **NG表現**: 「本日もお世話になりました」のような、**一日の終わりのお礼・過去形の感謝表現は使わない**。朝の時点でまだ起きていない出来事への感謝になるため不自然。
- 絵文字は使わない。実際に無い出来事を作り話ししない。無難で当たり障りのない内容にする。
## 毎日違う文面にする（重複回避 / 直近7日間）
- まず メモリ（AgentCore Memory）を参照し、直近7日間に書いた文面を確認する。
- その直近7日間の内容と同じ／ほぼ同じ文面は書かない。言い回しも話題（睡眠・食事・機嫌・体調・あいさつ等）も、過去7日と被らないように必ず変える。
- 過去7日の文面が見つからない場合は、新規に当たり障りのない文面を作る。
## ツールの呼び出し
- 文面が決まったら、それを `children-gateway` ツールに `message` として渡す。
## 下書き保存後：メモリに記録する
- `children-gateway` ツールによる下書き保存が**成功した後に**、今回下書き保存したコメント本文をメモリ（AgentCore Memory）に記録する。
- 記録する内容は「その日の日付（例: 2026-06-29）」と「実際に下書き保存したコメント本文」の組み合わせ。
- この記録が次回以降の実行で `## 毎日違う文面にする` の「直近7日間の文面」として参照され、重複回避が機能する。
- **下書き保存が成功していない場合は記録しない。** 保存に失敗した文面や、未送信・未保存の文面をメモリに残してはならない。
4. 工夫ポイント：「定型文おじさん」にならないために
放っておくとAIは連絡帳に毎日ほぼ同じ文章を吐く——この「定型文おじさん」をどう防ぐか、が本章のテーマです。
仕組み自体はシンプルで、AgentCore Memory に直近7日間の連絡帳を保存し、生成時に「これらとかぶらせないで」と指示する だけ。
……なのですが、ここで地味にハマったポイントがあったので共有します。
短期記憶は「セッションID」ごとに保持される
AgentCore Memory の短期記憶は、セッションID単位で記憶を持ちます。つまり、
セッションIDが変わると、AIにとっては「初対面の別人」になり、過去の記憶がまったく見えない
普通のチャットボットならこれは正しい挙動です。会話（セッション）ごとに記憶は分かれていてほしいので。
ところが今回は、EventBridge から毎朝あらたにLambdaが起動します。ここで毎回ランダムなUUIDをセッションIDにしてしまうと——
月曜のエージェント「元気です。よろしくお願いします。」（記憶ゼロ）
火曜のエージェント「元気です。よろしくお願いします。」（昨日の記憶ナシ）
水曜のエージェント「元気です。よろしくお願いします。」（以下略）
毎日が初対面。
これでは短期記憶を入れた意味がなくめでたく定型文おじさん
が完成します。
解決策：呼び出し側でセッションIDを固定する
そこで、Lambda から Harness を呼ぶときのセッションIDを、固定の文字列に決め打ちしました。日次実行のたびに同じIDを使うことで、すべての実行が「同一人物の記憶」を共有できます。
# AgentCore Memory はセッション単位で記憶を保持する。毎回同じIDを使うことで
# 日次実行が同一セッションを共有し、直近7日分の下書きを短期記憶から参照して重複回避できる。
#
# 文字数: "codmon-daily-fixed-session-v1-do-not-randomize" = 46文字
# (InvokeHarness の runtimeSessionId は 33-100 文字が必須)
_DAILY_SESSION_ID_DEFAULT = "codmon-daily-fixed-session-v1-do-not-randomize"
あとは Lambda が Harness を呼ぶときに、このIDを X-Amzn-Bedrock-AgentCore-Runtime-Session-Id ヘッダーに乗せて渡すだけ。「どのセッションの記憶を引き継ぐか」は、このヘッダー1本で決まります。
def handler(event, context):
event = event or {}
prompt = event.get("prompt") or DEFAULT_PROMPT
# ここで固定セッションIDを採用（イベントで明示指定がなければデフォルトの固定値）
session_id = event.get("session_id") or _default_session_id()
...
def _fire_harness(prompt: str, session_id: str):
...
headers = {
"Content-Type": "application/json",
# このヘッダーで「どのセッションの記憶を引き継ぐか」が決まる
"X-Amzn-Bedrock-AgentCore-Runtime-Session-Id": session_id,
}
...
これで毎朝起動するLambdaたちが同じセッション＝同じ短期記憶を共有するようになりました。(少しはBOT感を薄れさせることができたと思います……！)
5. セキュリティ：ID/PASSをコードに書いたら、その時点で負け
連絡帳アプリにログインする以上、ログインID・パスワードが必要です。
ここを雑にやると死にます。
- ❌ ソースコードに直書き → GitHubにpushした瞬間、世界中に公開
- ❌ 環境変数にベタ書き → 結局どこかに平文で残る
- ⭕ AWS Secrets Manager に保存して、実行時に取り出す
認証情報は Secrets Manager の金庫に入れて、ブラウザ操作をするLambdaが実行時にだけ取り出す設計にしています。
連絡帳アプリのログイン情報が漏れると、これはマジで洒落になりません。
自動化の便利さと引き換えに事故ったら本末転倒。ここだけは手を抜かない。
6. 運用してみて
導入してから、朝の連絡帳ストレスが少しだけ緩和された気がします。
子どもが体調不良の日や、お迎えがいつもと違う日はその日だけ下書きを書き換えればOKです。最後に人間が必ず内容を確認する前提なのでイレギュラーな日も運用上は問題ありません。
締め〆
- 作りながら Step Functions + Bedrock + DynamoDB でよくない？とか思いましたが、Harness の勉強も兼ねて作ってみたという部分もありました。思ったよりサクッといけたので、皆さんにもぜひおすすめです。
- 自動化のキモは「全部AIに任せること」ではなく、「人間が責任を持つ一線をどこに引くか」だと、この連絡帳エージェント作成を通じて学びました。
……と、ここまで散々語っておいてなんですが 保育園の先生との連絡帳は、本来AIにやらせるべきものではありません。 毎日子どもを見てくれている先生との大事なコミュニケーションの場です。今回はあくまで学習用に作ったものということで今後はもっと早起きしてちゃんと自分の手で書こうと思います.
おすすめ参考書
私のバイブル：「通称ピンク本」