はじめに

こんにちは！KDDIアイレットで、26新卒の営業として日々勉強中の縄田です。
私は文系出身で、IT業界もクラウドも未経験の状態からこの世界に入りました。
現在は営業の新卒として、商談への同席や営業の基礎をOJTで学ぶだけでなく、AWSやGoogle Cloudを中心に技術の勉強も進めています。
そんな中、学習を続けていて一つ悩みがありました。

「勉強した内容を、結局忘れてしまう」

という問題です。

その場では理解したつもりでも、数日後には曖昧になっている。
資格勉強をしている方なら、一度は経験したことがあるのではないでしょうか。

そこで、

「学習した内容を登録したら、復習すべき日に自動でSlackから教えてくれる仕組みを作れないか？」

と思ったことが、今回のBot開発のスタートでした。
そして今回は、エンジニアの同期などに依頼するのではなく、非エンジニアである自分自身で設計・構築してみることにしました。

まず作ったもの

今回作ったのは、Slack上から学習内容を登録すると、あらかじめ設定した復習日に自動でSlackへ通知してくれるBotです。
たとえばSlackで、

/study S3とEBSの違い

と入力すると、

登録しました！

学習内容：S3とEBSの違い

復習予定：
1回目：翌日
2回目：3日後
3回目：7日後
4回目：30日後

という形で登録されます。
そして復習日になると、Botから、

📚 今日の復習です！

1. S3とEBSの違い

思い出してから、必要に応じて学習メモを確認しましょう。

というDMが届きます。
今回はまず初期版として、

1日後 → 3日後 → 7日後 → 30日後

という復習間隔を設定しました。
今後は回答結果や理解度に応じて、この復習間隔自体を変化させていく予定です。

システム構成

今回使った主なサービスは以下です。

Slack
  ↓
Cloud Run
  ↓
Firestore

Cloud Scheduler
  ↓
Cloud Run
  ↓
Firestore
  ↓
Slack

役割を簡単に整理すると、

サービス 役割
slack 学習内容の登録・復習通知
Cloud Run Botのプログラムを実行
Firestore 学習内容・復習日を保存
Cloud Scheduler 毎日決まった時間に復習対象を確認
Slack API BotからユーザーへDMを送信

という構成です。
実際に動いている処理は非常にシンプルです。

学習内容を登録する
↓
復習日を計算する
↓
Firestoreに保存する
↓
毎朝Schedulerが確認する
↓
今日が復習日の内容を取得する
↓
Slackへ通知する

という流れです。

実際に書いたコード

今回、PythonとFlaskを使ってCloud Run上で動かしています。
たとえば /study が実行されたときは、Slackから学習テーマを受け取ります。

@app.route("/slack/study", methods=["POST"])
def study():
    user_id = request.form.get("user_id")
    topic = request.form.get("text", "").strip()

if not topic:
return "学習テーマを入力してください。"

today = datetime.now(TOKYO)

そこから復習日を計算します。

review_dates = [
    today + timedelta(days=1),
    today + timedelta(days=3),
    today + timedelta(days=7),
    today + timedelta(days=30),
]

そしてFirestoreへ保存します。

db.collection("studies").add({
    "user_id": user_id,
    "topic": topic,
    "created_at": today,
    "review_dates": review_dates,
    "review_count": 0,
})

一方、毎朝Cloud Schedulerから呼び出される処理では、Firestoreに保存されたデータを確認します。

@app.route("/daily-review", methods=["GET"])
def daily_review():
    today = datetime.now(TOKYO).date()

docs = db.collection("studies").stream()

復習日と今日の日付が一致していたら、そのテーマを抽出します。

for review_date in data.get("review_dates", []):
    review_date_jst = review_date.astimezone(TOKYO).date()

if review_date_jst == today:
user_id = data.get("user_id")
topic = data.get("topic")

最後にSlack APIを使ってDMを送信します。

slack_api(
    "chat.postMessage",
    {
        "channel": channel_id,
        "text": text,
    },
)

もちろん最初からこのコードを書けたわけではありません。
むしろ今回一番勉強になったのは、コードを書くことより、動かない原因を一つずつ切り分けていく過程でした。

当然、すんなりとは動かなかった

今回が自分にとって初めての実構築だったこともあり、かなり多くの壁にぶつかりました。

1, 違うGoogle Cloudプロジェクトに作っていた

最初の大きなミスは、Cloud Shellで操作しているGoogle Cloudプロジェクトと、Firestoreを作成したプロジェクトが異なっていたことです。

その結果、

The database (default) does not exist

というエラーが発生しました。
当初はコードがおかしいのかと思いましたが、原因はもっと手前にありました。
「いま自分がどのプロジェクトを操作しているのか」
というクラウドでは非常に基本的な部分です。

ここで、

gcloud config set project ...

などを使い、実行対象のプロジェクトを明示的に確認する重要性を学びました。

2. IAM権限が足りない

Cloud Runをデプロイしようとすると、次々に権限エラーが発生しました。
Artifact Registry、Cloud Logging、Cloud Storage、Firestoreなど、Cloud Runが裏側でさまざまなGoogle Cloudサービスと連携しているためです。
そこでサービスアカウントに必要なIAMロールを一つずつ付与していきました。

この経験から、
「Cloud Runを使う」
という一言の裏側でも、実際には複数サービスとIAMによる認証・認可が関わっていることを実感しました。

AWSのIAMを資格学習として勉強していたときとは、理解の深さがまったく違いました。
実際に403エラーを踏むと、IAMの意味がよく分かります。

3. Pythonのバージョンでアプリが起動しない

Cloud Runへのデプロイ自体は成功したものの、アプリが起動しない問題も発生しました。
原因をログから調べると、Python 3.14と利用ライブラリの組み合わせによるエラーでした。
そこでPython 3.13を明示的に指定。

.python-version

に、

3.13

を設定することで解決しました。
ここでは、
「デプロイ成功＝アプリケーションが正常に動いている、ではない」
ということを学びました。
Cloud Runのログを確認し、どのレイヤーで失敗しているのかを見ることが重要でした。

4. UTCと日本時間

Cloud Run上で、

datetime.now()

を使っていたところ、日本時間とズレる可能性があることにも気づきました。
そこで、

ZoneInfo("Asia/Tokyo")

を利用して、日本時間を明示しました。

today = datetime.now(ZoneInfo("Asia/Tokyo"))

クラウド上のサーバーは、自分のPCと同じ時間設定で動いているとは限りません。
これは実際にクラウドでアプリを動かして初めて意識したポイントでした。

5. Slackのユーザー名とUser IDは別物

SlackへのDM送信テストでもエラーが発生しました。

最初は、

@nawata_xxxxx

のようなSlack上の名前を指定していました。
しかしSlack APIが必要としていたのは、

UXXXXXXXXXX

という内部的なMember IDでした。正しいUser IDを渡すことで、無事DMが届きました。
画面上では同じ「ユーザー」に見えても、APIでは別のID体系を使っている。
これも、APIを実際に触ったからこそ分かったことでした。

「AIがあれば誰でも作れる」だけではなかった
今回の構築では、AIをかなり活用しました。
コード生成、エラーの読み解き、Cloud Runの設定、IAMの切り分け、Slack APIの実装など、多くの場面でAIと対話しながら進めています。

その意味では、
以前であればエンジニアへ依頼しなければ作れなかったものを、非エンジニア自身で作れる可能性は確実に広がっている
と感じています。

ただ、実際にやってみて分かったのは、
AIに「Botを作って」とお願いすれば、全部勝手に完成する
という話ではないということです。

たとえば今回だけでも、
・Cloud Runとは何か
・Firestoreとは何か
・HTTPリクエストとは何か
・IAMとは何か
・サービスアカウントとは何か
・APIとは何か
・UTCとJSTの違い
・ログをどう読むか
といった最低限の理解は必要でした。

AIが強力なのは、分からない部分をその場で聞きながら、実装まで進められることだと思います。

つまりAIによって、エンジニアリングの知識が不要になったのではありません。
むしろ、「学びながら作る」ためのハードルが劇的に下がったという表現の方が近いと感じています。

非エンジニアも「設計・構築する側」へ

今回このBotを作りながら、社内キックオフイベント「UNITE DAY」で聞いた話を思い出しました。
特に印象に残っているのが、AI時代における社内の内製化についての話です。
AIによって、これまでエンジニアが中心だった設計・構築の領域に、非エンジニアも関われるようになる。
今回、自分自身がその一つの実例になれたのではないかと思っています。

私は、

文系出身
IT未経験
2026年新卒

そして現在の職種は、

営業

です。

それでもAIとクラウドサービスを組み合わせることで、ゼロから、
要件を考え、構成を決め、Cloud Runへデプロイし、データベースを作り、APIを連携し、自動実行させる
ところまで実際に構築することができました。

もちろん、プロのエンジニアと同じレベルになったという話ではありません。
それでも、
「非エンジニアだから作れない」という境界線は、確実に薄くなっている
と感じています。

エンジニアが多い会社だからこそ、非エンジニアの内製化にも価値がある

KDDIアイレットでは、多くのエンジニアがクラウドやAIの技術を使ってお客様を支援しています。
一方で、営業をはじめとする非エンジニアも存在します。
私は、AI時代においてはこの非エンジニア層も、会社の技術的な価値をさらに広げられる存在になるのではないかと考えています。

営業自身が、「こんなものを作れそうだ」と考え、簡単なプロトタイプを作り、エンジニアと技術的な会話ができる。

そうなれば、お客様に提供できる価値は、単純なエンジニアの人数だけでは測れなくなるはずです。

営業が課題を聞くだけではなく、

課題を聞く → 解決策を考える → 試しに作ってみる → エンジニアと一緒にさらに高度化する

という動きができるようになる。

これは、AI時代のSIerやクラウドインテグレーターにとって、かなり大きな可能性だと思っています。

今回はまだPhase 1

今回完成したのは、あくまで最初のフェーズです。
現在は、

学習内容を登録
↓
復習日を計算
↓
Firestoreへ保存
↓
指定日にSlack通知

というところまでです。
今後はPhase 5まで発展させる予定です。

Phase 1：復習リマインド ← 今ここ
Slackから学習テーマを登録し、決められた日に自動通知。
Phase 2：AIによる復習問題生成
登録されたテーマをもとに、Geminiが復習問題を自動生成。
Phase 3：Slack上で回答・AI採点
ユーザーがSlackで回答すると、AIが内容を評価。正解 　惜しい　 理解が不十分
などを判定し、その場で解説します。
Phase 4：理解度に応じた復習間隔の最適化
固定の、
1日 → 3日 → 7日 → 30日
ではなく、
完全に理解 → 次回は14日後
少し曖昧 → 3日後
不正解 → 翌日
のように復習日を変えていきます。
Phase 5：学習履歴・苦手分野の可視化
最終的には、
AWS Networking：理解度 55%
IAM：理解度 80%
Storage：理解度 90%
といった形で、自分の学習状況を分析できるところまで持っていきたいと思っています。
ここまで完成すれば、単なるリマインドBotではなく、
自分専用のAI学習コーチ
に近づいていきます。

最後に

今回一番大きかったのは、Botが完成したことそのものではありません。
「自分でも作れる」と分かったことです。

以前の自分であれば、Cloud Run、Firestore、API、IAM という単語を見ただけで、
これはエンジニアがやるものと思っていたはずです。

でもAIを使いながら一つずつ理解し、エラーを解決していけば、非エンジニアでも実際に動くものを作るところまで到達できました。

これを読んでいる非エンジニアの方にも、
「コードを書いたことがないから自分には無理」
と最初から決めつけず、一度小さなものを作ってみてほしいと思います。

完璧な設計ができなくてもいい。
最初からすべて理解していなくてもいい。

AIに聞きながら、
作る → 動かない → 調べる → 直す → 動く
を繰り返していく。

その過程そのものが、非常に良い技術学習になりました。

そして、エンジニアだけではなく営業を含めた非エンジニアまで「作れる側」になっていけば、会社としてお客様に提供できる価値もさらに大きくなるはずです。

今回のStudy Reminder Botは、その小さな第一歩です。

次はPhase 2。
Geminiによる復習問題の自動生成に挑戦していきます。