スタッフに翌週の出勤希望を聞く。TimeTreeに予定が入っているか確認する。入っていない人を探す。個別に催促する。最後に日付ごとの出勤者をまとめる。

一つひとつは小さい作業です。ただ、毎週続くと管理する側の負担はかなり大きい。

これまでは出勤管理にTimeTreeを使っていました。TimeTree自体が悪いわけではありません。予定共有ツールとしては便利です。

ただ、現場で使っていると別の問題が出ます。

TimeTreeを開く習慣がない人。通知が来ても後回しにする人。性格的に細かい入力が苦手な人。そういうスタッフは、決められた日時までに出勤予定を入力できないことがありました。

そのときに出てくるのが「出勤を入れ忘れた」という言い訳です。

では、入れ忘れを防ぐにはどうすればいいのか。

考えた結論はシンプルでした。

確実に日常で使うツールに、出勤確認そのものを組み込む。

そして、未入力ならその場所で催促の通知が来るようにする。

そこで今回は、普段ほぼ確実に使うLINEグループを入口にして、翌週の出勤希望を回収・集計・催促できるBotを作りました。

僕は本職のエンジニアではありません。ただ、店舗運営の現場で何が面倒なのかは分かります。

その現場感をもとに、AIを使いながら要件整理、設計、実装、LINE Developers設定、Supabase設計、Vercelデプロイまで進めました。

何を作ったか

作ったのは、LINEグループ内で使える週次出勤確認Botです。

スタッフはLINEグループで 登録リンク や 入力リンク と送るだけで、出勤入力用の画面を開けます。管理者は 集計 と送るだけで、翌週の日付ごとの出勤者一覧を確認できます。

まだ入力していない人は 未入力 で確認でき、毎日12時には未入力者へ自動でメンション催促も送られます。

LINEトークだけで複雑なカレンダー画面を再現するのではなく、入口・通知・集計はLINEグループ、入力だけはLIFFフォームに分けました。

この分け方にしたことで、スタッフ側は「LINEから開いて押すだけ」、管理者側は「LINEで集計と送るだけ」というシンプルな運用にできます。

なぜLINEにしたか

今回一番大事にしたのは、機能の多さではなく「現場で使われるかどうか」です。

出勤管理ツールとして多機能なものを作ることはできます。時間入力、承認フロー、希望順位、履歴管理など、入れようと思えばいくらでも入れられます。

ただ、最初から機能を盛ると、入力する側が面倒になります。

今回の目的は、シフト管理システムを作ることではありません。

まずは「翌週の出勤希望を確実に回収すること」です。

だから入力対象は翌週の月曜から土曜に固定しました。日曜日は店休日の想定なので外しました。時間入力もやめました。

出勤するか、休みか、未定か。必要ならメモを書く。

それだけに絞っています。

LINEで管理し、未入力ならLINE上で通知が来る。この形にすれば「入れ忘れた」はかなり通りにくくなります。

LINEは日常的に見る。そこに未入力通知が来る。それでも入力しないなら、単なる入れ忘れではなく、見て見ぬふりに近い状態になります。

出勤確認の仕組みを作るというより、言い訳が生まれにくい運用を作る。そこが今回の一番の狙いでした。

技術的にやったこと

表面上は「LINEでリンクを返すBot」に見えますが、実際には小さな業務システムとして作っています。

使った主な技術は、Next.js、React、TypeScript、Supabase、LINE Messaging API、LIFF、Vercel、Vercel Cronです。

スタッフ登録では、LIFFからLINEのIDトークンを取得し、LINEユーザーIDとグループIDをSupabaseに保存します。同じ人が再登録しようとした場合は、重複登録ではなく「登録済み」として扱うようにしました。

出勤入力では、翌週の営業日ごとに 出勤 / 休み / 未定 を選びます。翌週に1回も出勤を選ばなかった場合は、出勤なし理由を必須にしました。

管理者が 集計 と送ると、日付ごとの出勤者、メモ、未入力者、翌週出勤なしの人と理由がLINEに返ります。

また、LINE Webhookの署名検証、Webhookイベントの重複処理防止、LIFFリンクの署名付きstate、Cron APIのBearer token保護も入れています。

単なる自動返信ではなく、実運用で使う前提の最低限の守りも入れた構成です。

非エンジニアがAIを使って作って感じたこと

今回やってみて感じたのは、非エンジニアでも「現場の課題を具体的に説明できる」なら、AIを使ってかなり実用に近いものを作れるということです。

ただし、AIに丸投げすれば勝手に良い業務システムができるわけではありません。

入力対象を今週にするのか翌週にするのか。日曜日を含めるのか。時間入力を必須にするのか。催促は個別DMなのかグループメンションなのか。1週間出勤しない人の理由を必須にするのか。

こういう判断は、技術の問題というより運用の問題です。

AIは実装を手伝ってくれます。でも、何を作るべきか、どこまで作るべきか、現場で使われる形は何かを決めるのは人間側です。

僕はコードだけを見ていたわけではありません。

これをスタッフが本当に使うか。管理者が毎週ラクになるか。入れ忘れの言い訳を潰せるか。

そこを見ながら、AIと一緒に形にしていきました。

この経験で対応できること

今回の経験をもとに、以下のような案件に対応できます。

• LINE公式アカウントBot構築
• LINE LIFFフォーム開発
• 店舗向け業務効率化システム
• 小規模チーム向けの出勤・シフト確認ツール
• 未入力者への自動催促Bot
• Supabaseを使った軽量な業務アプリ
• Vercel Cronを使った定期通知システム
• Webhook連携を含むサーバレスアプリ開発

「普段使っているLINEで業務を回したい」

「スタッフに新しいアプリを入れさせずに入力・集計をしたい」

「毎週の確認作業や催促を減らしたい」

こういう課題に対して、現場運用に合わせた小さな業務Botを設計・実装できます。

今回作ったものは、華やかなサービスではありません。

でも、現場で毎週発生する面倒を減らすための道具です。

僕にとっては、非エンジニアがAIを使ってどこまで実務に踏み込めるのかを試す、かなり実感のある開発になりました。

ChatGPT、Claude、Gemini……AIの進化はまるで毎日何かが変わる。でも気づけばタブを開いては閉じ、タイムラインを眺めては流し、いつのまにか「大事な情報を見逃していないか」という漠然とした不安だけが残っていた。

「もう、ボットに全部やらせればいい」

そう思って作り始めたのが、今回紹介する AI News Discord Bot だ。

何をするツールか

一言で言えば、毎朝自動でAIニュースを収集し、日本語に翻訳してDiscordに投稿するボットだ。

情報源は大きく2つある。

まずRSSフィード。TechCrunch AI、The Verge、VentureBeat、MIT Tech Review、HuggingFace Blog、OpenAI News……英語圏の主要メディアから最新記事を引っ張ってくる。

もうひとつがX（旧Twitter）のAPI。AIに関する公式アカウントの投稿や、「AI副業で稼いだ」「このプロンプトが神だった」系のエンゲージメントの高いツイートを48時間以内で収集する。

そして集めた情報をClaude Haiku（Anthropicの軽量・高速モデル）に渡す。Haikuは「これは本当に有益か？」をフィルタリングし、英語記事なら日本語に翻訳・3文で要約して返してくれる。

最終的にDiscordのチャンネルへ、カテゴリ別にきれいに整形されて届く。

5つのカテゴリで情報を分類

ボットが仕分けするカテゴリはこの5つだ。

• 最新AIニュース ── 新モデルのリリース、主要企業の発表、AI規制の動向
• AI技術情報 ── 新アーキテクチャ、ベンチマーク比較、推論最適化など開発者向け情報
• Claude/ChatGPT/Gemini Tips ── 実際に使えるプロンプトや新機能の活用法
• AI副業マネタイズ（国内） ── note、Brain、Coconalaなど日本のプラットフォームでの収益化事例
• AI副業マネタイズ（海外） ── Fiverr、Gumroad、PromptBaseなど海外での稼ぎ方

「全部追いたいけど全部は無理」という状況を、ボットが解決してくれる。

作ってみて気づいたこと

このボットを動かし始めて、情報との付き合い方が変わった。

朝起きてDiscordを開くと、すでに整理された情報が届いている。英語が苦手でも関係ない。HaikuがすべてをきれいにAI翻訳して、要点だけ届けてくれる。

「知らなきゃいけない」という焦りがなくなった。

X APIを使っているのがポイントで、フォロワーが多いアカウントの人気ツイートだけを拾えるので、バズった有益情報を漏らさず収集できる。いいね数とRTに重みをつけてスコアリングしているので、エンゲージメントが高い投稿が上に来る仕組みだ。

使用技術まとめ

• Python 3
• X API v2（Bearer Token認証）
• RSS解析（urllib）
• Claude Haiku API（フィルタリング・翻訳・要約）
• Discord Webhook（Embed形式で整形送信）
• Windowsタスクスケジューラ（PowerShellで毎朝9時に自動実行）

「ゼロからリスタート」している今だからこそ

このブログのテーマは「ゼロからのリスタート」だ。

正直、技術的にゼロから始めた人間が、X APIとClaudeをつないで情報収集を自動化できるようになるとは思っていなかった。

でも動いた。毎朝9時に、ちゃんとDiscordに届く。

これはちっちゃな自信になった。「自分でも作れる」という感覚は、次への一歩を軽くしてくれる。

まだまだ改善したいことは山ほどある。でもまず「動くものを作った」という事実が、今の自分には一番大事なことだと思っている。

• JavaScriptを「ブラウザ上で処理する言語」として説明できる
• 最低限のDOM操作（ボタン→表示切替）ができる
• 「フォーム」「開閉」「表示切替」の入口が分かる

1. まず結論（30秒）

JavaScriptは、Webページに動きや処理を追加するための言語です。

2. JavaScriptでできること（よく使う順）

• クリックしたら開閉（メニュー / FAQ）
• フォーム入力チェック（必須、メール形式、文字数など）
• APIからデータ取得して表示（少し進んだ内容）

3. 最低限覚える概念（これだけで戦える）

• 変数（データを入れる箱）
• 条件分岐（if）
• 関数（処理のまとまり）
• イベント（clickなど）
• DOM操作（HTMLの要素を選んで変更）

4. 実際にどう役立つ？

• 「メニューが開かない」→ clickイベント / class付け替え
• 「フォームが送れない」→ バリデーション / 送信処理

5. よくある誤解

• 誤解: JSは全部覚えないと使えない
  正しくは: まずは「DOM操作とフォーム」からで十分

6. ミニ課題（30分）

FAQのアコーディオンを作ります（1クリックで開閉）。

• 質問をクリックしたら回答が開く
• 開いてる項目だけクラスを付ける
• CSSで開いてる項目の背景色を変える

ブログに載せるもの（アウトプット）
・アコーディオン開閉前（アコーディオンのキャレットダウン▼）

・アコーディオン開閉後（アコーディオンのキャレットアップ▲）

7. 理解チェック

1. JavaScriptは何をする言語？
2. イベントとは？
3. DOM操作は何を触っている？

まとめ

• 今日の結論: JSで「動き」と「処理」を作る
• 次にやること: 裏側（バックエンド）の役割へ

• CSSを「見た目を当てるルール」として説明できる
• スマホ対応（レスポンシブ）の基本（メディアクエリ）がわかる
• 「スマホで崩れる」をCSSで直す発想が持てる

1. まず結論（30秒）

CSSはHTMLに対して「こう見せる」を指定する言語です。
スマホ対応は画面幅に応じてCSSルールを切り替えるのが基本です。

2. CSSの基本（これだけ）

• セレクタ: どこに当てるか（例：.btn）
• プロパティ: 何を変えるか（例：color）
• 値: どう変えるか（例：red）

3. スマホ対応の考え方（最短）

先に“スマホ”を作る（モバイルファースト）

• スマホで縦に積む
• 画面が広くなったら横並びにする

メディアクエリ例

• /* まずスマホ基準 */
• .cards { display: grid; gap: 16px; }
• /* 画面が広いときだけ横並びを増やす */
• @media (min-width: 768px) {
• .cards { grid-template-columns: repeat(3, 1fr); }
• }

4. 実際にどう役立つ？

• 「スマホで崩れてる」→ まずCSSの幅/余白/画像/フォントを疑う
• 「ボタンが押しにくい」→ タップ領域（高さ/余白）をCSSで調整
• 「表示が遅い」→ 画像最適化が主、でもCSSの整理も対象

5. よくある誤解

• 誤解: とりあえず !important
  正しくは: まず「どのCSSが勝っているか」を確認（優先順位）

6. ミニ課題（30分）

• HTMLでカード3枚を用意
• PCは横並び（Grid or Flex）
• スマホは縦並び（メディアクエリで切り替え）

ブログに載せるもの（アウトプット）

• • PC表示スクショ

• • スマホ表示スクショ（iPhone 14 pro max）

7. 理解チェック

1. CSSは何をする？
2. メディアクエリは何のため？
3. スマホ対応の基本方針は？（一言）

まとめ

• 今日の結論: CSSで見た目、メディアクエリでスマホ対応
• 次にやること: JSで「動き」へ

• HTMLを「文章の意味付け（構造化）」として説明できる
• よく使うタグ（h1/p/a/img/ul/li/section）を使える
• WordPress投稿が最終的にHTMLになるイメージが持てる

1. まず結論（30秒）

HTMLは、Webページの内容に意味（構造）を与える言語です。
「見出し」「本文」「リスト」などを正しく分けるほど、読みやすく・SEOにも強くなります。

2. よく使うタグ（最優先）

• h1〜h6: 見出し（h1が一番大きい）
• p: 段落（文章）
• a: リンク
• img: 画像
• ul / li: 箇条書き
• section: 章・まとまり

3. “いいHTML”の考え方

• 見た目より先に意味を優先する
• 「divだらけ」より、見出し/段落/リストを正しく使う
• h1は基本1つ（ページの主題）

4. 実際にどう役立つ？

• LP制作：見出し構造が読みやすさ・SEOに直結
• WordPress：ブロックエディタで書いても、最終的にHTMLになって表示される
• 表示崩れの原因が「HTMLの構造」なこともある（タグ閉じ忘れ等）

5. よくある誤解

• 誤解: divをいっぱい使えばOK
  正しくは: まずは「意味のあるタグ」で構造化すると後が楽

6. ミニ課題（30分）

「求人LPの骨組み」をHTMLだけで作ります（CSSなし）。

• h1（ページの主題）を1つ決める
• sectionで「待遇」「給与例」「応募方法」「FAQ」を分ける
• FAQはul/liで箇条書きにする
• CTAはaタグでリンクを作る（仮でOK）

ブログに載せるもの（アウトプット）

• • HTMLのスクショ
  • 「h1は何にしたか」1行

□作ったページのブラウザ表示のスクショ

□作ったページのHTMLのスクショ

7. 理解チェック

1. HTMLは何をする言語？
2. h1は基本いくつ？
3. aタグは何？

まとめ

• 今日の結論: HTMLは内容を「意味付けして構造化」する
• 次にやること: CSSで見た目とスマホ対応へ

この記事のゴール

• 今回やった操作（clone / status / add / commit / push）を、自分の言葉で説明できる
• not a git repository と nothing to commit を見ても焦らない
• Git Bashで「ショートカットが違う」問題の回避策を持つ

方法1: 基本フロー（clone→add→commit→push）

結論：Gitは 変更を作る → add → commit → push の繰り返しです。

1. GitHubから取得（clone）
   • 例：git clone https://github.com/koollovesato-maker/tradingview
   • please complete authentication in your browser... が出たら、ブラウザで認証を完了
2. フォルダへ移動（ここが最重要）
   • 例：cd tradingview
   • clone直後は自動で中に入らないので、必ず移動する
3. 状態確認
   • git status
   • On branch main が出ていればOK
4. 変更を作る（新規ファイル作成）
   • 例：echo "test" > test.txt
   • この時点では Untracked files（未追跡）として表示される
5. 変更を選ぶ（add）
   • 例：git add test.txt
   • add は「次のcommitに入れる変更を選ぶ」
6. 履歴として保存（commit）
   • 例：git commit -m "test.txt を追加（練習）"
   • commitはローカルに履歴を残す操作
7. GitHubへ送る（push）
   • 例：git push
   • pushでGitHubに反映される

方法2: よく出る表示（エラーに見えるけど正常）

2-1. nothing to commit, working tree clean

これはエラーではありません。
意味は 保存すべき差分がない です（変更が0ならcommitは発生しない）。

トラブルシューティング

1) not a git repository が出る

• fatal: not a git repository (or any of the parent directories): .git

原因：今いるフォルダ（または親フォルダ）に .git がない＝Git管理されていない場所で実行している。

1. 今いる場所が正しいか確認
   • pwd（今いる場所）
   • ls -a（.git があるか）
2. cloneしたフォルダに移動
   • 例：cd tradingview

2) コピペで変な文字が混ざって失敗する（ブラケットペースト）

こういう表示が出たら、貼り付け時の制御文字が混ざっています。

• $ ^[[200~cd tradingview
• bash: $'\E[200~cd': command not found

1. 何も入力せずEnterを押してリセット
2. コマンドを手入力する
   • 例：cd tradingview

3) Ctrl+C / Ctrl+V の癖でミスる（Git Bashあるある）

Git Bashでは、Ctrl+C は多くの場合「中断」です（コピーではない）。

• VSCodeのターミナル: Ctrl+Shift+C（コピー） / Ctrl+Shift+V（貼り付け）
• Git Bash（mintty）: 右クリック貼り付け、または Shift+Insert など（設定次第）

確認コマンド（よく使うセット）

• 今の状態: git status
• 差分を見る: git diff
• 履歴を見る: git log --oneline
• どこにpushするか確認: git remote -v

ミニ課題（10分）

1. test.txt に1行追記する
   • 例：echo "line2" >> test.txt
2. 差分を確認
   • git diff
3. add → commit → push
   • git add test.txt
   • git commit -m "test.txt を更新（練習）"
   • git push

   □練習画像

理解チェック

1. not a git repository はどういう状態？
2. nothing to commit, working tree clean は何を意味する？
3. git add と git commit の役割の違いは？
4. commit したのに GitHub に反映されないとき、何が足りない？

まとめ

結論：変更を作る → add → commit → push が基本ループ。
commitできないのは「差分がない」だけで、エラーではありません。

今回触ったリポジトリ: https://github.com/koollovesato-maker/tradingview
タグ: #Git #GitHub #学習ログ #GitBash

• HTML/CSS/JSを「骨・見た目・動き」で説明できる
• 「どこを直せばいいか」の当たりが付く（超重要）

1. まず結論（30秒）

• HTML: 内容と構造（骨組み）
• CSS: 見た目（デザイン）
• JavaScript: 動き（操作・処理）

2. 直感で理解（たとえ）

HTML = 家の柱・間取り
CSS  = 壁紙・家具・色
JS   = 電気・自動ドア・インターホン

3. 具体例（切り分け）

• 文字を変える → HTML（またはWordPressの本文/テンプレ）
• 色や余白を変える → CSS
• ボタン押したら開閉したい → JavaScript
• フォームが送れない → JS（バリデーション） or サーバ側（バックエンド）も疑う

4. 最低限の用語

• DOM: ブラウザがHTMLをツリー構造にしたもの（JSが触る対象）
• class: CSSやJSで狙うための目印

5. よくある誤解

• 誤解: CSSで文章を追加できる
  正しくは: 内容はHTML。CSSは装飾が役割
• 誤解: JSは後回しでいい
  正しくは: 最低限のDOM操作/フォームは早めに触ると理解が一気に進む

6. ミニ課題（30分）

1つのページで「骨・見た目・動き」を全部体験します。

• HTMLで「見出し・本文・ボタン」を作る
• CSSで「色・余白・中央寄せ」を当てる
• JSで「ボタン押したら文字が変わる」を作る

ブログに載せるもの（アウトプット）

• HTML/CSS/JSそれぞれ何を担当したか（各1行）
• 動いた様子のスクショ（可能ならGIF）

7. 理解チェック

1. HTML/CSS/JSはそれぞれ何担当？
2. 「スマホで崩れる」はまずどこを見る？
3. DOMとは何？

まとめ

• 今日の結論: Webは「骨組み（HTML）+見た目（CSS）+動き（JS）」

この記事では、GitとGitHubの違い・できること・最低限の用語を整理します。

Gitとは何か

Gitは、ファイルの変更履歴を管理する仕組み（バージョン管理）です。

• いつ、どこを、どう変更したかが残る
• 過去の状態に戻せる
• 安全に試せる（壊しても戻せる）

GitHubとは何か

GitHubは、Gitのデータ（履歴）をネット上に置いて共有できるサービスです。

• チームで同じコードを共有できる
• バックアップとして使える
• 成果物（ポートフォリオ）として見せられる

Git / GitHubでできること

① 履歴管理

• どの変更で壊れたか追える
• 戻したいときに戻せる

② 差分確認

• どこが変更されたかを見比べられる

③ チーム開発

• 複数人で同時に作業しても管理しやすい

最低限覚える用語

• リポジトリ：プロジェクト一式の保管場所
• コミット：変更の保存（スナップショット）
• ブランチ：作業用の分岐（本体を壊さず試せる）
• プッシュ：ローカルの変更をGitHubへ送る
• プル：GitHubの変更を手元へ持ってくる

初心者はまず何ができればOK？

1. Gitでコミットできる
2. GitHubにプッシュできる
3. 差分が見られる

この3つができれば、学習にも案件にも十分役立ちます。

まとめ

• Gitは「変更履歴を管理する仕組み」
• GitHubは「履歴を共有・保存する場所」
• 初心者は「コミット→プッシュ→差分確認」からでOK

タグ：#Git #GitHub #履歴管理 #初心者

この記事では、APIの意味・仕組み・よくある例を、初心者向けに整理します。

APIとは何か

API（Application Programming Interface）とは、 他のプログラムやサービスから機能を利用できるようにした“入り口（窓口）” のことです。

APIでできること（例）

• 地図表示（Google Mapsなど）
• 決済（クレジット決済、QR決済）
• ログイン（Googleログイン、LINEログイン）
• 天気情報の取得
• SNS投稿の取得

仕組みのイメージ（超ざっくり）

APIは基本的に「リクエスト（お願い）→レスポンス（返事）」で動きます。

あなた（Web/アプリ）
   ↓ リクエスト（データちょうだい）
API（窓口）
   ↓ レスポンス（データ返す）
あなた（画面に表示）

よく見る言葉：エンドポイント / メソッド

• エンドポイント：APIのURL（どこにお願いするか）
• メソッド：何をしたいか（取得/作成など）

例（イメージ）：

GET /users   → ユーザー一覧を取得（Read）
POST /users  → ユーザーを作成（Create）

APIを理解すると何ができるようになる？

• 外部サービス連携ができる（地図、決済、予約、通知など）
• フロント（画面）と裏側（サーバー）を分けて設計できる
• Webサービス/アプリの“会話の仕組み”が分かる

まとめ

• APIは「サービスの機能を使うための窓口」
• 基本は「リクエスト→レスポンス」
• CRUDやJSONとセットで理解すると強い

タグ：#API #Webサービス #外部連携 #初心者

この記事では、CRUDの意味・具体例・WordPressとの関係までを、教科書的に整理します。

CRUDとは何か

CRUDとは、データに対する基本操作4つを並べた略語です。

CRUDが重要な理由

• Webサービスの多くは「データを管理する仕組み」だから
• 管理画面や予約システムは、ほぼCRUDで説明できるから
• 要件整理（何ができれば完成か）がラクになるから

具体例：応募管理ツール（イメージ）

• Create：応募フォームから応募データを登録する
• Read：管理画面で応募一覧を見る
• Update：対応状況（未対応→対応済み）を変更する
• Delete：重複応募や不要データを削除する

WordPressとCRUDの関係

WordPressは「投稿」というデータを扱うCMSです。 つまり、WordPressの基本機能はCRUDそのものです。

• 投稿を作成する（Create）
• 投稿を表示する（Read）
• 投稿を編集する（Update）
• 投稿を削除する（Delete）

まとめ

• CRUDは「データ操作の基本4つ（作成・取得・更新・削除）」
• Webサービスの多くはCRUDで整理できる
• WordPressもCRUDの考え方で理解できる

タグ：#CRUD #Webサービス #WordPress #開発基礎