Blog on Bossagyu Blog

技術習熟の3つのモデル：ドレイファス・守破離・意識的能力の4段階

Sun, 19 Apr 2026 00:00:00 +0900

概要

私たちが何らかの技能を身につけていく過程は、一様ではありません。初めは手順書に頼り、やがて状況に応じた判断ができるようになり、さらに進むと無意識のうちに最適な動作ができるようになります。こうした段階的な変化を捉えるために、古くから多くのモデルが提唱されてきました。

本記事では、代表的な3つの習熟フレームワーク、ドレイファスモデル、守破離、意識的能力の4段階 を紹介し、それぞれの背景・段階構造・特徴を比較します。自分の現在地を知り、次の一歩を設計し、他者の学びを支えるための道具として、これらのモデルがどう使えるかを整理します。

なぜ習熟段階を理解するのか

習熟を段階として捉えるメリットは、大きく3つあります。

1つ目は 自己理解 です。自分が今どの段階にいるのかが分かると、次に何を身につけるべきかが見えてきます。新人の頃に必要だった「手順を正確にこなす力」と、中堅になってから求められる「状況に応じた判断力」はまったく別のスキルです。段階を意識することで、努力の方向を誤らずに済みます。

2つ目は 学習設計 です。最終ゴールだけを見て漠然と努力するより、段階的なマイルストーンを置くほうが継続しやすく、成長も確認しやすくなります。段階ごとに「今の自分に合った学び方」が変わることも、多くのモデルが示しています。

3つ目は 他者理解 です。後輩を指導する場面や、チームメンバーの成長を見守る場面で、相手がどの段階にいるかを見立てられれば、必要な支援や関わり方を選びやすくなります。

ただし、モデルは現実そのものではありません。人の習熟は連続的で、領域ごとに段階がばらつくこともあります。本記事で紹介するモデルは、あくまで思考の補助線として使うものだと覚えておきたいところです。

ドレイファスモデル

出自と背景

ドレイファスモデルは、Stuart E. Dreyfus と Hubert L. Dreyfus の兄弟が1980年にカリフォルニア大学バークレー校でまとめた報告書 “A Five-Stage Model of the Mental Activities Involved in Directed Skill Acquisition” で提唱されたモデルです。もともとは米空軍科学研究局の委託研究であり、パイロットの訓練やチェスプレイヤー、自動車運転など、幅広い技能習得を題材に論じられました。

兄のスチュワートはオペレーションズ・リサーチ、弟のヒューバートは哲学（現象学）を専門とし、2人の共著として「熟達者の判断が必ずしも明示的なルールで説明できない」という問題意識を形にしたのがこのモデルです。

後にソフトウェアエンジニアリングの領域でも、Andy Hunt の著書『Pragmatic Thinking and Learning』などを通じて広く紹介され、エンジニアの成長を語るときの共通言語のひとつになりました。

5段階の構造

ドレイファスモデルは、人が未経験の状態から熟達者に至るまでを5段階で描きます。

flowchart LR
A[Novice
初心者] --> B[Advanced Beginner
上級初心者]
B --> C[Competent
一人前]
C --> D[Proficient
中堅]
D --> E[Expert
達人]

クリックで拡大

各段階の特徴は次の通りです。

1. Novice（初心者） 状況を文脈から切り離し、与えられたルールに従って行動します。ルールを守ることで精一杯で、例外や全体像を見る余裕はありません。料理で言えばレシピ通りに計量する段階、運転で言えばマニュアル通りにペダルとハンドルを操作する段階です。

2. Advanced Beginner（上級初心者） 経験を積む中で、状況に付随する特徴に気づき始めます。とはいえ、どの特徴が重要でどれが些末かの見分けはまだつかず、すべてを同じ重みで扱いがちです。先輩に細かく質問し、カバーできないケースに直面して初めて学ぶ段階と言えます。

3. Competent（一人前） 複数の情報の中から重要なものを選び、自分で目標と計画を立てられるようになります。ルールは内面化され、状況への適応度が上がります。一方で「正解はひとつではない」ことが分かり始め、判断の責任を感じて悩むのもこの段階の特徴です。

4. Proficient（中堅） 状況を全体として捉え、何が起きているかを俯瞰できるようになります。過去の類似ケースを引き寄せてパターン認識で判断し、細部をルールで詰めるのはその後、という順序に逆転していきます。直感と分析の両方を使い分けるハイブリッドな段階です。

5. Expert（達人） 明示的なルールを意識せず、状況に埋め込まれた「正解」を直感的に導きます。熟達した医師が患者を一目見て診断の見当をつけたり、棋士が盤面を見て候補手を絞り込むように、分析より前に判断が立ち上がります。ただし、環境が通常と大きく異なる場合には、達人も意識的な分析に戻る必要があります。

段階を移るときに起きる認知の変化

このモデルが示唆する重要な点は、段階を上がるにつれて認知の中心が「分析」から「パターン認識」、さらに「直感」へと移っていくことです。これは単に速くなるというだけでなく、何を見ているかが変わるという質的な変化です。

また、上位段階に進むには、ルールに従うだけでなく「ルールを文脈に応じて解釈する経験」が欠かせません。ドレイファス兄弟は、熟達とは暗黙知の獲得であり、それを教科書的に教えることは難しいと繰り返し指摘しています。

守破離

出自と背景

守破離（しゅはり）は、日本の武道・茶道・華道といった伝統芸能の世界で発達してきた修行の段階論です。明確な成文として現れるのは江戸時代中期の茶人、川上不白（1719-1807）による『不白筆記』と伝えられていますが、その源流はさらに古く、世阿弥（1363-1443）が『風姿花伝』で示した「序破急」の発想や、千利休の教えに連なるとされます。

利休道歌として知られる一首に、「規矩作法守り尽くして破るとも離るるとても本（もと）を忘るな」という歌があり、これが守破離という言葉を象徴する一節としてよく引用されます。型を守り、やがて破り、さらに離れても、根本を忘れてはならない——というメッセージです。

近年では、アジャイル開発・スクラム・デザインパターン学習など、西洋生まれの知的実践にも「守破離」が応用され、日本語圏のソフトウェア業界では共通語のひとつになりました。

3段階の構造

守破離は、師匠と弟子の関係を前提とした3段階のモデルです。

flowchart LR
A[守
型を守る] --> B[破
型を破る]
B --> C[離
型から離れる]
C -.新たな型.-> A

クリックで拡大

守師匠や流派の教える型を、忠実に守って稽古する段階です。自分の解釈を加えずに正確に反復することが求められます。「なぜこうするのか」は後から分かることが多く、まずは身体や思考に型を染み込ませる時期と言えます。

破守の段階で体得した型を下敷きに、他流派の型や自分の工夫を取り入れて型を破っていく段階です。単なる反抗ではなく、比較と検証を通じて型を吟味する営みであり、ここで初めて「なぜそうするのか」が腹落ちしてきます。

離型から離れ、独自の境地に至る段階です。このとき、型を捨てたのではなく、型が自分の一部になっているため、外から見ると型に縛られず自在に動いているように見えます。利休道歌の「本を忘るな」は、離に至っても根は守の時期にあることを戒めた言葉です。

西洋モデルとの違い

ドレイファスモデルが個人の認知活動の変化を描くのに対し、守破離は 共同体の中で型を受け渡す ことを前提にしています。型には流派の歴史や先人の知恵が凝縮されており、それを正確に受け継ぐ「守」の時期がまずある、という思想です。

また、守破離は 学習者の主体性の現れ方 を段階で示すモデルとも読めます。守では受容、破では対話と検証、離では創造が中心になり、単なるスキル上達ではなく人格の成熟や世界観の拡張まで含意する点も特徴的です。

現代での応用例

ソフトウェア開発のパターン学習: まずはデザインパターンをそのまま適用し（守）、プロジェクトに応じて変形し（破）、最終的にはパターンに頼らず問題に応じた設計ができる（離）、という学びの道筋として語られます。
スクラム導入: 最初はスクラムガイドに忠実に従い、チームが習熟してきたら自分たちのコンテキストに合わせてイベントや役割を調整する、という段階論として引用されます。
新人教育全般: 手順書通りに動く時期、自分なりの工夫を加える時期、仕組みそのものを設計する時期、という段階的な関わり方の指針として用いられます。

意識的能力の4段階

出自と背景

「意識的能力の4段階（Four Stages of Competence、別名 Conscious Competence Ladder）」は、1970年代に米国の Gordon Training International で講師を務めた Noel Burch が提唱したとされる学習モデルです。ただし、原型となる考え方はそれ以前から存在し、心理学者 Abraham Maslow に帰属させる説、同じく Thomas Gordon に帰属させる説もあるため、出典は完全に一意ではありません。

このモデルの特徴は、学習者の 能力の有無 と、その能力の 自覚の有無 という2つの軸を組み合わせて段階を整理している点です。能力そのものだけでなく「自分が何を知らないか／知っているか」をどれだけ意識できているかに焦点を当てており、学習者の心理面を扱いやすいフレームとして知られています。

4段階の構造

4つの段階は、意識と能力の組み合わせで次のように表現できます。

quadrantChart
title 意識的能力の4段階
x-axis "能力が低い" --> "能力が高い"
y-axis "自覚していない" --> "自覚している"
quadrant-1 "意識的有能"
quadrant-2 "意識的無能"
quadrant-3 "無意識的無能"
quadrant-4 "無意識的有能"

クリックで拡大

1. Unconscious Incompetence（無意識的無能） できないことに気づいていない段階です。自分が何を知らないかすら分からないため、学習の必要性を感じません。ここからの脱出には、外部からのフィードバックや「できない現実」に気づかせる刺激が鍵になります。

2. Conscious Incompetence（意識的無能） できないことを自覚した段階です。4段階のうち心理的にもっともストレスが大きく、「自分はダメだ」と感じて学習を諦めやすい危険地帯でもあります。ここを抜けるには、小さな成功体験を重ねられる環境と、安心して失敗できる関係性が重要です。

3. Conscious Competence（意識的有能） 意識的に注意を払えばできる段階です。手順を頭で辿りながら実行する状態で、疲れやすく遅くはあるものの、一貫して成果を出せるようになります。ここでの繰り返しが、次の段階への足場になります。

4. Unconscious Competence（無意識的有能） 考えなくても自然にできる段階です。タスクが自動化され、他のことに注意を振り向ける余裕が生まれます。ただし、言語化できないがゆえに「なぜそうするのか」を人に教えるのが難しくなる、という新たな課題が出てきます。

心理面の意義と第5段階

このモデルが他のモデルと異なるのは、意識的無能の「谷」 をはっきりと示すところです。学ぶとは、まず「できない自分」に直面することであり、ここでの支援が学習の継続可否を大きく左右します。

近年では、第4段階の先に Conscious Competence of Unconscious Competence（反省的有能／教えられる状態） を置く派生モデルも提唱されています。これは、自動化された自分のスキルを再度意識に上げ、他者に言語化して伝えられる状態を指します。指導者・メンターに求められるのは、まさにこの第5段階の能力と言えるでしょう。

3つのフレームワークの比較

3つのモデルは一見似ているようで、着目している側面が異なります。まずは観点ごとに整理してみます。

観点	ドレイファスモデル	守破離	意識的能力の4段階
段階数	5	3	4（派生で5）
観察する側面	判断・行動の質	型との関係	能力と自覚の組み合わせ
文化的背景	西洋・哲学（現象学）	日本・伝統芸能	西洋・教育心理
成立時期	1980年	江戸時代（源流はより古い）	1970年代
学習者像	個人の認知の変化	共同体で型を受け継ぐ存在	意識と無意識を行き来する存在
熟達の到達点	直感的判断	型から離れた自在さ	自動化された能力

共通点

表面的な違いを超えて、3つのモデルには共通する構造もあります。

初期は外部依存、後期は自律 という方向性。ルールや型、意識的な努力から始まり、やがてそれらが内面化されていく。
最上位は言語化しにくい熟達 として描かれる。ドレイファスの Expert、守破離の離、4段階の Unconscious Competence はいずれも、明示的な指示を超えた領域を指します。
段階の移行は直線ではない。どのモデルも、ある段階に必要な学びが次の段階に進むと不要になるのではなく、基礎として残り続けることを前提にしています。

相違点

一方で、着目点の違いは明確です。

ドレイファスモデル は「判断の質」にフォーカスします。ルール適用から直感的パターン認識への変化を、認知科学的に描いています。
守破離 は「型との関係」にフォーカスします。型を共有する共同体の存在と、そこから個として独立していく筋道を描きます。
意識的能力の4段階 は「意識の状態」にフォーカスします。特に「自分ができないと気づく瞬間」という心理的な転換点を明示的に扱います。

どのモデルをいつ使うか

自分や他者の行動パターンを分析したい とき → ドレイファスモデル
師匠・メンター・型が存在する学習環境 で段階を捉えたいとき → 守破離
学習者の心理状態を支えたい、挫折しそうな人を支援したい とき → 意識的能力の4段階

目的に応じて使い分けるのが実践的で、1つに絞る必要はありません。むしろ、ある学習者の状況を複数のモデルで見てみると、違う側面が見えてくることが多いでしょう。

応用：学習とプロダクト設計への活かし方

これらのフレームワークは、単なる知識として知っておくだけでなく、実際の学習や設計の現場で使える道具でもあります。代表的な3つの使い道を挙げておきます。

1. 自分の学習計画に使う

身につけたい領域について、「今の自分はどの段階にいるか」を複数のモデルから見立ててみます。ドレイファスで見ると一人前だが、意識的能力で見ると実はまだ意識的有能に留まっている——といったズレを発見すると、次に必要な学習行動が具体化します。たとえば「型を破る経験」が足りないと気づけば、他流派（他チーム・他ツール・他言語）の考え方に触れに行く計画が立てられます。

2. 他者の指導・メンタリングに使う

相手の段階によって、効果的な関わり方は変わります。

初心者・無意識的無能には、正確なルールや型を示し、まず安全に反復できる環境を用意する
意識的無能の学習者には、小さな成功体験の積み重ねと、失敗を肯定する関係性を
一人前・破の段階には、判断の責任を渡し、意思決定のレビューで支える
中堅・達人・離の段階には、自身の経験を言語化して後進に伝える機会を

相手の段階を見誤ると、助けが押しつけになったり、放任が放置になったりします。段階を意識することで、関わり方を選ぶ精度が上がります。

3. プロダクト・アプリ設計に使う

ユーザーの習熟段階に応じた設計も、これらのモデルから多くを学べます。

オンボーディング: 初心者には明示的なガイド・手順・制約を設ける。守の段階に相当します。
モード切替: 習熟したユーザーには、ショートカットや上級モードを用意し、ルール表示を減らす。破や離の段階に寄り添う設計です。
意識的無能の支援: 「何が分からないか分からない」状態のユーザーには、何を学ぶべきかを明示する診断・チュートリアルが効きます。
段階の移行を促すフィードバック: 単にエラーを返すのではなく、今の段階の次に進むヒントを示す設計は、学習者としてのユーザーに寄り添う姿勢の表れです。

こうした視点でプロダクトを眺め直すと、機能の優先順位や情報設計が整理しやすくなります。

まとめ

技術習熟を段階として捉えるフレームワークは数多くありますが、ドレイファスモデル・守破離・意識的能力の4段階の3つは、それぞれ着目点が異なり、互いを補い合う関係にあります。

ドレイファスモデルは 判断の質の変化 を
守破離は 型との関係の変化 を
意識的能力の4段階は 意識と能力の組み合わせ を

描くモデルです。

モデルはあくまで地図であり、領土そのものではありません。現実の学習者は連続的に変化し、領域によって段階がばらつきもします。それでも、地図があれば自分の現在地を見立て、次の一歩を選ぶ助けになります。自分自身の学習、他者への関わり、そしてプロダクト設計のそれぞれで、これらのモデルを状況に応じて使い分けてみると、見えてくるものが変わるはずです。

参考文献

Stuart E. Dreyfus, Hubert L. Dreyfus, “A Five-Stage Model of the Mental Activities Involved in Directed Skill Acquisition”（1980年, U.S. Air Force Office of Scientific Research）
Andy Hunt『Pragmatic Thinking and Learning: Refactor Your Wetware』（2008年, Pragmatic Bookshelf）
川上不白『不白筆記』
世阿弥『風姿花伝』
Noel Burch, “The Four Stages for Learning Any New Skill”（1970年代, Gordon Training International）

FastAPIでCRUD APIを作る入門チュートリアル

Sat, 28 Feb 2026 00:00:00 +0900

概要

FastAPIは、Pythonで高性能なAPIを構築するためのWebフレームワークです。以下の特徴があります。

型ヒントベース: Pythonの型ヒントを活用し、リクエスト・レスポンスの自動バリデーションを実現
自動ドキュメント: Swagger UI（OpenAPI）が自動生成され、ブラウザからAPIをテスト可能
高速: Starlette + Pydanticをベースにしており、Node.jsやGoに匹敵するパフォーマンス

この記事では、FastAPIを使ってTODOアプリのCRUD APIを作成する手順を解説します。

前提条件

Python 3.11以上
uvがインストール済み（MacでUVを用いてPythonの開発環境を構築するを参照）

環境構築

まず、プロジェクトを作成し、必要なパッケージをインストールします。

1
2
3


uv init fastapi-todo
cd fastapi-todo
uv add fastapi uvicorn

fastapiがWebフレームワーク本体、uvicornがASGIサーバーです。

Hello World

まずは最小構成でFastAPIの動作を確認します。main.pyを作成してください。

1
2
3
4
5
6
7
8


from fastapi import FastAPI

app = FastAPI()


@app.get("/")
def read_root():
 return {"message": "Hello, FastAPI!"}

サーバーを起動します。

1

uv run uvicorn main:app --reload

--reloadオプションを付けると、コードの変更時に自動でリロードされます。

ブラウザで http://localhost:8000 にアクセスすると、以下のレスポンスが返ります。

1

{"message": "Hello, FastAPI!"}

Swagger UIの確認

FastAPIの大きな魅力は、自動生成されるAPIドキュメントです。http://localhost:8000/docs にアクセスすると、Swagger UIが表示されます。

ここからAPIを直接テストできるため、開発中はcurlやPostmanなしでも動作確認が可能です。

CRUD APIの実装

TODOアプリのCRUD APIを実装していきます。

モデルの定義

まず、PydanticモデルでTODOのデータ構造を定義します。main.pyを以下のように書き換えてください。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


from fastapi import FastAPI, HTTPException
from pydantic import BaseModel


app = FastAPI()


class TodoCreate(BaseModel):
 title: str
 completed: bool = False


class TodoResponse(BaseModel):
 id: int
 title: str
 completed: bool


todos: dict[int, dict] = {}
next_id: int = 1

TodoCreate: 新規作成・更新時のリクエストボディ
TodoResponse: レスポンスの型定義
todos: インメモリのデータストア（dict）
next_id: IDの自動採番用カウンター

作成（POST）

1
2
3
4
5
6
7


@app.post("/todos", response_model=TodoResponse)
def create_todo(todo: TodoCreate):
 global next_id
 todo_data = {"id": next_id, "title": todo.title, "completed": todo.completed}
 todos[next_id] = todo_data
 next_id += 1
 return todo_data

response_model=TodoResponseを指定することで、レスポンスの型がSwagger UIに反映されます。

一覧取得（GET）

1
2
3


@app.get("/todos", response_model=list[TodoResponse])
def list_todos():
 return list(todos.values())

個別取得（GET）

1
2
3
4
5


@app.get("/todos/{todo_id}", response_model=TodoResponse)
def get_todo(todo_id: int):
 if todo_id not in todos:
 raise HTTPException(status_code=404, detail="Todo not found")
 return todos[todo_id]

存在しないIDの場合はHTTPExceptionで404エラーを返します。

更新（PUT）

1
2
3
4
5
6
7


@app.put("/todos/{todo_id}", response_model=TodoResponse)
def update_todo(todo_id: int, todo: TodoCreate):
 if todo_id not in todos:
 raise HTTPException(status_code=404, detail="Todo not found")
 todo_data = {"id": todo_id, "title": todo.title, "completed": todo.completed}
 todos[todo_id] = todo_data
 return todo_data

削除（DELETE）

1
2
3
4
5
6


@app.delete("/todos/{todo_id}")
def delete_todo(todo_id: int):
 if todo_id not in todos:
 raise HTTPException(status_code=404, detail="Todo not found")
 del todos[todo_id]
 return {"detail": "Todo deleted"}

完成したコード

上記をすべてまとめたmain.pyの全体像は以下のとおりです。

 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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58


from fastapi import FastAPI, HTTPException
from pydantic import BaseModel


app = FastAPI()


class TodoCreate(BaseModel):
 title: str
 completed: bool = False


class TodoResponse(BaseModel):
 id: int
 title: str
 completed: bool


todos: dict[int, dict] = {}
next_id: int = 1


@app.post("/todos", response_model=TodoResponse)
def create_todo(todo: TodoCreate):
 global next_id
 todo_data = {"id": next_id, "title": todo.title, "completed": todo.completed}
 todos[next_id] = todo_data
 next_id += 1
 return todo_data


@app.get("/todos", response_model=list[TodoResponse])
def list_todos():
 return list(todos.values())


@app.get("/todos/{todo_id}", response_model=TodoResponse)
def get_todo(todo_id: int):
 if todo_id not in todos:
 raise HTTPException(status_code=404, detail="Todo not found")
 return todos[todo_id]


@app.put("/todos/{todo_id}", response_model=TodoResponse)
def update_todo(todo_id: int, todo: TodoCreate):
 if todo_id not in todos:
 raise HTTPException(status_code=404, detail="Todo not found")
 todo_data = {"id": todo_id, "title": todo.title, "completed": todo.completed}
 todos[todo_id] = todo_data
 return todo_data


@app.delete("/todos/{todo_id}")
def delete_todo(todo_id: int):
 if todo_id not in todos:
 raise HTTPException(status_code=404, detail="Todo not found")
 del todos[todo_id]
 return {"detail": "Todo deleted"}

動作確認

サーバーを起動して、Swagger UIから動作確認を行います。

1

uv run uvicorn main:app --reload

http://localhost:8000/docs にアクセスし、以下の順にテストしてください。

1. TODOの作成

POST /todosを開き、「Try it out」をクリックして以下のJSONを入力します。

1
2
3
4


{
 "title": "買い物に行く",
 "completed": false
}

「Execute」をクリックすると、以下のようなレスポンスが返ります。

1
2
3
4
5


{
 "id": 1,
 "title": "買い物に行く",
 "completed": false
}

2. 一覧取得

GET /todosを実行すると、作成したTODOの一覧が返ります。

3. 更新

PUT /todos/1でcompletedをtrueに変更してみましょう。

1
2
3
4


{
 "title": "買い物に行く",
 "completed": true
}

4. 削除

DELETE /todos/1を実行すると、TODOが削除されます。GET /todosで空の配列が返ることを確認してください。

まとめ

この記事では、FastAPIを使ってTODO管理のCRUD APIを作成しました。FastAPIの主な利点をまとめます。

Pydanticモデルによるリクエスト・レスポンスの自動バリデーション
Swagger UIによるインタラクティブなAPIドキュメント
Pythonの型ヒントだけでAPIの仕様が定義できるシンプルさ

今回はインメモリのデータストアを使いましたが、実際のアプリケーションではSQLAlchemyなどのORMを使ってデータベースと連携することになります。

MacでUVを用いてPythonの開発環境を構築する - Python環境構築
GCSとGemini File Search APIを自動同期するイベント駆動バックエンドの設計 - FastAPIの実践例

GCSとGemini File Search APIを自動同期するイベント駆動バックエンドの設計

Sun, 15 Feb 2026 00:00:00 +0900

概要

デジタル庁主催の「法令×デジタル」ハッカソン第三弾に参加し、法令横断検索プロダクト「Lawve」を開発しました。Lawveは、e-Gov法令データやユーザーがアップロードしたドキュメントを横断的に自然言語検索できるプロダクトです。

この記事では、筆者が担当したバックエンドのアーキテクチャ設計について解説します。バックエンドの主な責務は「Google Cloud Storage（GCS）にファイルが配置・削除されたとき、Gemini File Search APIの状態を自動的に同期する」ことです。

システム全体像

Lawveのシステム構成は以下の通りです。

flowchart TB
subgraph ユーザー
U[ブラウザ]
end
subgraph GCP
subgraph フロントエンド
FE[Cloud Run
Next.js]
end
subgraph バックエンド
CR[Cloud Run
FastAPI]
end
subgraph ストレージ・データ
GCS[(Cloud Storage)]
FS[(Firestore)]
end
subgraph イベント基盤
EA[Eventarc]
end
subgraph AI
GEMINI[Gemini File
Search API]
end
end
subgraph 外部API
EGOV[e-Gov
法令API]
end
U --> FE
FE --> GEMINI
FE --> FS
FE --> EGOV
FE -->|ファイルアップロード| GCS
GCS -->|イベント通知| EA
EA -->|CloudEvents| CR
CR -->|登録・削除| GEMINI
CR -->|ダウンロード| GCS

クリックで拡大

各コンポーネントの役割

コンポーネント	役割
Cloud Run（Next.js）	フロントエンド。検索UI、ファイルアップロード、検索結果の表示
Cloud Run（FastAPI）	バックエンド。GCSのイベントを受けてGemini File Search APIを同期
Cloud Storage	ドキュメントの保管場所。Single Source of Truth
Eventarc	GCSのファイル変更イベントをCloud Runにルーティング
Gemini File Search API	ドキュメントの全文検索・セマンティック検索を提供
Firestore	ドキュメントメタデータ、コメント情報の管理
e-Gov法令API	法令データの取得

この記事では、バックエンドの Cloud Run（FastAPI）の設計に焦点を当てます。

イベント駆動アーキテクチャの設計

なぜイベント駆動を選んだか

法令検索プロダクトでは、ドキュメントがGCSに配置されたタイミングでGemini File Search APIに自動登録される必要があります。フロントエンドからの同期APIを作る方法もありますが、以下の理由でイベント駆動アーキテクチャを採用しました。

疎結合: フロントエンドはGCSにファイルを配置するだけでよく、バックエンドの存在を意識しない
信頼性: GCSのイベントをEventarcが確実に検知し、Cloud Runに配信する
運用ツールとの親和性: CLIやスクリプトからGCSにファイルを配置しても同じように同期される

Eventarcによるイベントルーティング

Eventarcは2種類のGCSイベントを監視し、Cloud Runのエンドポイントにルーティングします。

イベント	トリガー条件
`google.cloud.storage.object.v1.finalized`	ファイルがGCSにアップロードされたとき
`google.cloud.storage.object.v1.deleted`	ファイルがGCSから削除されたとき

Cloud RunのエンドポイントはCloudEventsフォーマットでイベントを受信します。

1
2
3
4
5
6
7
8


@app.post("/")
async def handle_storage_event(request: Request):
 headers = dict(request.headers)
 body = await request.body()
 event = from_http(headers, body)

 result = event_handler.process(event)
 return result

ファイルアップロード時の処理フロー

ファイルがGCSに配置されると、以下のフローで処理されます。

イベント受信・パスフィルタリング: file-search/archive/ プレフィックスを持つファイルのみ処理対象とする
メタデータ抽出: GCSパスから law_id と source_type を自動抽出
既存ドキュメント削除: 同じ source_path を持つドキュメントがあれば削除（重複防止）
ファイルダウンロード: GCSからローカルの一時ファイルにダウンロード
File Search Storeに登録: メタデータを付与してGemini File Search APIに登録

1
2
3
4
5
6


class EventHandler:
 def _handle_event_by_type(self, event_type, bucket_name, file_name):
 if event_type == "google.cloud.storage.object.v1.finalized":
 self._handle_file_upload(bucket_name, file_name)
 elif event_type == "google.cloud.storage.object.v1.deleted":
 self._handle_file_delete(bucket_name, file_name)

ファイル削除時の処理フロー

ファイルがGCSから削除されると、対応するドキュメントをGemini File Search APIからも削除します。

イベント受信・パスフィルタリング
メタデータでFile Search Store内を検索: source_path メタデータで一致するドキュメントを特定
ドキュメント削除: File Search Storeから該当ドキュメントを削除

Gemini File Search APIとの統合

GCPエコシステムでの統一

Lawveではインフラ全体をGCPで統一する方針を取りました。RAGサービスとしてOpenAIやPineconeなど他の選択肢もありますが、Cloud Run、GCS、EventarcとシームレスにつながるGemini File Search APIを採用しています。

File Search Storeの概要

Gemini File Search Storeは、ドキュメントを登録するとベクトル化・インデックス化を行い、セマンティック検索を提供するマネージドサービスです。バックエンドでは以下の操作を行います。

ドキュメント登録: ファイルとメタデータをアップロード
ドキュメント検索: メタデータをキーに既存ドキュメントを検索
ドキュメント削除: 不要になったドキュメントを削除

メタデータを活用した管理

各ドキュメントには以下の3つのメタデータを付与し、管理に活用しています。

メタデータ	用途	例
`law_id`	法令ID。法令の一意識別に使用	`323AC0000000205`
`source_type`	ドキュメントの分類	`user`, `doc`, `admin`
`source_path`	GCSの完全パス。ドキュメントの一意識別に使用	`gs://bucket/file-search/archive/user/323AC0000000205/医療法.txt`

source_path はGCSパスそのものであるため、GCSのファイルとFile Search Store内のドキュメントを一意に対応付けることができます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


metadata = {
 "law_id": law_id,
 "source_path": source_path,
 "source_type": source_type
}

custom_metadata = [
 {"key": key, "string_value": value}
 for key, value in metadata.items()
]

汎用性を持たせた設計の工夫

パスベースのメタデータ抽出

バックエンドは法令データに限定せず、GCSの特定パスに配置されたあらゆるファイルを処理できるよう設計しています。パスの規約は以下の通りです。

1

gs://<bucket>/file-search/archive/<source_type>/<law_id>/<file_name>

パスから source_type と law_id を正規表現で自動抽出します。

1
2
3
4
5
6
7
8


# パスパターン
GCS_PATH_PATTERN = r'file-search/archive/([^/]+)/([^/]+)/.+'

def parse_gcs_path(gcs_path: str) -> Tuple[Optional[str], Optional[str]]:
 match = re.search(GCS_PATH_PATTERN, gcs_path)
 if match:
 return match.group(1), match.group(2)
 return None, None

この設計により、法令データだけでなく社内文書や技術ドキュメントなど、任意のドキュメントを同じ仕組みで管理できます。source_type を変えるだけで分類を追加でき、パス規約さえ守ればバックエンドのコード変更は不要です。

GCSとGemini File Search APIの状態同期の保証

GCSを Single Source of Truth（信頼できる唯一の情報源）とし、File Search Storeの状態を常にGCSと一致させることを設計原則としています。

アップロード時の冪等性: 同じファイルを再度アップロードした場合、既存のドキュメントを削除してから再登録します。これにより重複を防ぎつつ、内容の更新にも対応できます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


def process_file_upload(self, bucket_name, file_path):
 source_path = f"gs://{bucket_name}/{file_path}"

 # 既存ドキュメントの確認・削除
 self._delete_existing_documents(source_path)

 # 新規アップロード
 law_id = extract_law_id(file_path)
 local_file_path = self.gcs_client.download_to_temp_file(bucket_name, file_path)
 # ...
 success = self.store_client.upload_file(local_file_path, file_path, metadata)
 return success

削除時の連動: GCSからファイルが削除されると、File Search Storeからも対応するドキュメントが自動的に削除されます。source_path メタデータをキーに検索し、一致するドキュメントを削除します。

1
2
3
4
5
6
7
8


def process_file_delete(self, bucket_name, file_path):
 source_path = f"gs://{bucket_name}/{file_path}"

 documents = self.store_client.find_documents_by_source_path(source_path)
 if not documents:
 return False

 return self.store_client.delete_document(documents[0])

ローカルダウンロード経由の設計

GCSからGemini File Search APIへの登録は、一度ローカルの一時ファイルにダウンロードしてから行う設計にしています。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


def download_to_temp_file(self, bucket_name, file_path):
 _, ext = os.path.splitext(file_path)
 if not ext:
 ext = ".txt"

 temp_fd, temp_path = tempfile.mkstemp(suffix=ext)
 os.close(temp_fd)

 blob.download_to_filename(temp_path)
 return temp_path

直接アップロードする方がシンプルですが、ローカルに一度保存することで以下のメリットがあります。

拡張性: 将来ExcelをCSVに変換するなど、アップロード前のファイル加工処理を挟める
MIME判定: ファイル拡張子を保持することで正確なMIMEタイプ判定が可能
デバッグ: 問題発生時にローカルファイルの内容を確認できる

エラーハンドリングと運用設計

常に200 OKを返す設計

Cloud RunのエンドポイントはEventarcからのリクエストに対し、エラーが発生しても常に200 OKを返します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


@app.post("/")
async def handle_storage_event(request: Request):
 try:
 headers = dict(request.headers)
 body = await request.body()
 event = from_http(headers, body)
 result = event_handler.process(event)
 return result
 except Exception as e:
 return {
 "status": "error",
 "message": f"Event processing failed: {str(e)}",
 "note": "Error logged and notified via Slack"
 }

これはEventarcのリトライを防ぐための設計です。エラー時に4xx/5xxを返すとEventarcがイベントを再送し、同じエラーが繰り返し発生します。結果としてSlack通知が重複し、ログが汚染されます。エラーはSlack通知とログで把握し、200 OKで受け取り済みとすることで運用上の問題を防いでいます。

Slack通知によるエラー監視

File Search Storeへのアップロード失敗時にはSlack Webhookでエラー通知を送信します。通知にはGCSパスとエラー詳細を含め、運用者が問題箇所を素早く特定できるようにしています。

このSlack通知による監視はハッカソンの開発規模では十分ですが、実運用ではCloud Monitoringによるアラート設定やCloud Loggingとの連携、Dead Letter Queueによる失敗イベントの再処理など、より堅牢な監視・リカバリの仕組みが必要になるでしょう。

遅延初期化によるクライアント管理

Gemini APIクライアントやGCSクライアントは遅延初期化（Lazy Initialization）を採用しています。

1
2
3
4
5


@property
def client(self) -> Optional[genai.Client]:
 if self._client is None and self.api_key:
 self._client = genai.Client(api_key=self.api_key)
 return self._client

APIキーが未設定の場合でもアプリケーションが起動でき、テスト環境やローカル開発時にすべての環境変数を揃えなくても動作します。

まとめ

Lawveのバックエンドは、以下の設計原則に基づいて構築しました。

イベント駆動による疎結合な自動同期: Eventarcを活用し、フロントエンドとバックエンドを疎結合に保ちつつGCSの変更を自動的にGemini File Search APIに反映
メタデータ駆動の汎用設計: パス規約からメタデータを自動抽出し、法令以外のドキュメントにも対応可能な拡張性を確保
GCSをSingle Source of Truthとした状態管理: 冪等なアップロードと連動削除により、GCSとFile Search Storeの状態を常に一致させる

イベント駆動アーキテクチャとGCPのマネージドサービスを組み合わせることで、少ないコードで信頼性の高いドキュメント同期基盤を実現できました。GCSにファイルを配置するだけで検索可能になるシンプルさは、ハッカソンの限られた時間内での開発にも大きく貢献しました。

ソースコードはGitHubで公開しています。

MacでUVを用いてPythonの開発環境を構築する（Python環境構築）
OpenAI Response APIの使い方まとめ（OpenAI APIの利用）

【初心者向け】掃除リマインダーBotの使い方チュートリアル

Sat, 07 Feb 2026 20:00:00 +0900

このチュートリアルで学べること

掃除リマインダーBotの基本的な使い方を、5つのステップで学びます。

友だち追加
タスクを追加する
通知を設定する
通知を受け取る
タスクを完了する

所要時間は約5分です。一緒にやってみましょう！

Step 1: 友だち追加

まずはBotを友だちに追加します。

以下のQRコードをLINEで読み取るか、リンクをタップしてください。

友だち追加はこちら

友だち追加が完了すると、トーク画面が開きます。

Step 2: タスクを追加する

次に、管理したい掃除タスクを登録します。

トーク画面で以下のように入力して送信してください。

1

追加 掃除機 7

これは「掃除機を7日ごとにリマインドする」という意味です。

Botから「掃除機を追加しました」と返信が来れば成功です。

ポイント

「追加」の後にスペースを入れる
タスク名は自由（トイレ、お風呂、換気扇など）
日数は何日ごとにリマインドするかを指定

Step 3: 通知を設定する

タスクを追加したら、通知を受け取る曜日と時間を設定しましょう。

以下のように入力して送信してください。

1

通知設定 月水金 7

これは「月・水・金の7時に通知する」という意味です。

「通知設定を更新しました」と返信が来れば設定完了です。

ポイント

曜日は続けて入力（月水金、毎日なら月火水木金土日）
時間は0〜23の数字で指定

Step 4: 通知を受け取る

設定した曜日・時間になると、期限切れのタスクがあれば通知が届きます。

通知には以下の情報が含まれます。

タスク名
何日超過しているか（例: +3日）

超過日数が多いほど、優先的に掃除すべきタスクです。

Step 5: タスクを完了する

掃除が終わったら、Botに報告しましょう。

以下のように入力して送信してください。

1

完了 掃除機

「掃除機を完了しました」と返信が来れば完了です。

タスクの期限がリセットされ、次は7日後に再び通知されます。

ポイント

完了のタスクはスペース区切りで複数複数指定可能です。
- 完了掃除機トイレ

まとめ

お疲れさまでした！これで基本的な使い方は完了です。

覚えておきたいコマンド

やりたいこと	コマンド
タスクを追加	`追加 [タスク名] [日数]`
タスクを完了	`完了 [タスク名]`
通知を設定	`通知設定 [曜日] [時間]`
残りタスクを確認	`残り`

次のステップ

より詳しい機能については、以下の記事をご覧ください。

掃除リマインダーBotの全機能紹介

ぜひ活用して、掃除を習慣化しましょう！

掃除を忘れない！掃除リマインダーLINE Bot（全機能の紹介）
LINE Messaging APIの登録と使い方（LINE Bot開発の基礎）

AWS Lambda + LINE Botで掃除リマインダーを作る

Sat, 07 Feb 2026 19:00:00 +0900

概要

家族で使える掃除リマインダーLINE Botを作りました。この記事では、その技術的な実装について解説します。

完成したBotはこちら: 掃除リマインダーBot

アーキテクチャ

flowchart LR
subgraph ユーザー操作
A[LINE User]
end
subgraph AWS
B[API Gateway]
C[Lambda
process_user_message]
D[(S3
JSON)]
E[Lambda
push_message_periodically]
F[EventBridge
毎時実行]
end
A -->|メッセージ送信| B
B --> C
C <--> D
E <--> D
F -->|トリガー| E
E -->|通知| A

クリックで拡大

使用サービス

サービス	用途
API Gateway (HTTP API)	LINEのWebhook受信
Lambda	メッセージ処理、定期通知
S3	ユーザーごとのタスクデータ保存
EventBridge	定期実行スケジュール

なぜこの構成か

サーバーレス: 使った分だけ課金、運用負荷ゼロ
S3: RDSより安価、JSONでシンプルに管理
SAM: Infrastructure as Codeでデプロイ管理

プロジェクト構成

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


clean-bot/
├── lib/ # コアモジュール
│ ├── clean_task.py # タスク状態管理
│ ├── message.py # コマンドパーサー
│ ├── line.py # LINE API
│ └── s3_client.py # S3操作
├── test/ # テスト
├── line_clean_bot.py # Lambdaエントリーポイント
├── template.yaml # SAMテンプレート
└── Makefile # 開発コマンド

実装のポイント

1. Lambdaエントリーポイント

2つのLambda関数を用意しています。

 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
32
33
34
35


# line_clean_bot.py

def process_user_message(event, context):
 """LINEメッセージのWebhookハンドラ"""
 body = json.loads(event.get('body'))

 # ユーザーID or グループIDを取得
 if body['events'][0]['source']['type'] == 'user':
 line_id = body['events'][0]['source']['userId']
 else:
 line_id = body['events'][0]['source']['groupId']

 message = body['events'][0]['message']['text']

 # S3からユーザーデータを取得
 s3client = S3client(BUCKET_NAME)
 obj_key = line_id + '.json'
 if not s3client.check_exist_object(obj_key):
 s3client.update_object(obj_key, '{"tasks": []}')

 # メッセージを処理して返信
 # ...

def push_message_periodically(event, context):
 """定期実行でリマインド通知を送信"""
 current_time = datetime.now() + timedelta(hours=9) # JST

 s3client = S3client(BUCKET_NAME)
 for obj_list in s3client.list_objects():
 clean_task = CleanTask(s3client.get_object_body(obj_list.key))

 # 通知条件を満たすか判定
 if clean_task.should_notify(current_time):
 # メッセージ送信
 # ...

2. タスクの期限管理

「前回から何日経過したか」でタスクの期限を判定します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# lib/clean_task.py

def __evaluate_cleanup_timing(self, task):
 """タスクが期限切れか判定"""
 task_time = datetime.strptime(task['updated_at'], self.date_format)
 return (self.now - task_time).days >= int(task['duration'])

def get_todo_tasks(self):
 """期限切れのタスク一覧を取得"""
 return [task for task in self.tasks
 if not task.get('paused', False)
 and self.__evaluate_cleanup_timing(task)]

3. 通知判定ロジック

ユーザーが設定した曜日・時間にのみ通知します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


def should_notify(self, current_time):
 """通知すべきか判定"""
 if not self.notification['enabled']:
 return False

 # 曜日チェック
 weekday_map = {0: '月', 1: '火', 2: '水', 3: '木', 4: '金', 5: '土', 6: '日'}
 current_weekday = weekday_map[current_time.weekday()]
 if current_weekday not in self.notification['days']:
 return False

 # 時刻チェック
 if current_time.hour < self.notification['hour']:
 return False

 # 今日すでに通知済みかチェック
 # ...

 return True

4. コマンドパーサー

シンプルな文字列分割でコマンドを解析します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# lib/message.py

def get_return_message(self, message, s3client):
 task_operation = self.__get_task_operation_name(message) # 最初の単語
 task_name = self.__get_task_name(message) # 2番目の単語

 if task_operation == '完了':
 for task_name in self.__get_all_task_name(message):
 self.clean_task.update_task_updated_at(task_name)
 s3client.update_object(self.object_keyname, self.clean_task.get_json())
 return "完了しました"

 if task_operation == '追加':
 duration = self.__get_duration(message) # 3番目の単語
 self.clean_task.add_task(task_name, duration)
 # ...

5. データ構造（JSON）

ユーザーごとに1つのJSONファイルをS3に保存します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


{
 "tasks": [
 {
 "task_name": "掃除機",
 "updated_at": "2024-01-01 12:00:00",
 "duration": 7,
 "paused": false
 }
 ],
 "notification": {
 "enabled": true,
 "days": ["月", "水", "金"],
 "hour": 7,
 "last_notified_at": "2024-01-01 07:00:00"
 }
}

SAMテンプレート

AWS SAMを使ってインフラを定義します。

 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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52


# template.yaml
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Parameters:
 ChannelAccessToken:
 Type: String
 NoEcho: true
 BucketName:
 Type: String
 Default: your-bucket-name

Globals:
 Function:
 Runtime: python3.11
 Timeout: 300
 Environment:
 Variables:
 CHANNEL_ACCESS_TOKEN: !Ref ChannelAccessToken
 BUCKET_NAME: !Ref BucketName

Resources:
 # メッセージ処理Lambda
 ProcessUserMessageFunction:
 Type: AWS::Serverless::Function
 Properties:
 Handler: line_clean_bot.process_user_message
 CodeUri: .
 Policies:
 - S3CrudPolicy:
 BucketName: !Ref BucketName
 Events:
 ApiEvent:
 Type: HttpApi
 Properties:
 Path: /process_user_message
 Method: ANY

 # 定期通知Lambda
 PushMessagePeriodicallyFunction:
 Type: AWS::Serverless::Function
 Properties:
 Handler: line_clean_bot.push_message_periodically
 CodeUri: .
 Policies:
 - S3CrudPolicy:
 BucketName: !Ref BucketName
 Events:
 ScheduleEvent:
 Type: Schedule
 Properties:
 Schedule: cron(0 * * * ? *)  # 毎時0分

デプロイ方法

1. 事前準備

AWS CLIの設定
SAM CLIのインストール
LINE Messaging APIのチャンネルアクセストークン取得

2. ビルド & デプロイ

1
2
3
4
5


# ビルド
sam build

# デプロイ
sam deploy --parameter-overrides ChannelAccessToken=your_token

3. LINE Webhook設定

デプロイ後に出力されるAPIエンドポイントを、LINE DevelopersコンソールでWebhook URLとして設定します。

ローカル開発

1
2
3
4
5
6
7


# ローカルAPIサーバー起動
sam local start-api --env-vars env.json

# テスト実行
curl -X POST http://localhost:3000/process_user_message \
 -H "Content-Type: application/json" \
 -d @events/line_message.json

コスト

月間コストの目安（100ユーザー想定）:

サービス	コスト
Lambda	ほぼ無料（無料枠内）
API Gateway	ほぼ無料（無料枠内）
S3	数円/月
合計	数円〜数十円/月

まとめ

サーバーレス構成で運用コストを最小化
S3 + JSONでシンプルなデータ管理
SAMでインフラをコード管理
「日数経過」という掃除に適した期限管理

ソースコードはGitHubで公開しています。

掃除を忘れない！掃除リマインダーLINE Bot

Sat, 07 Feb 2026 18:30:00 +0900

こんな悩みはありませんか？

「掃除機、最後にかけたのいつだっけ…」
「トイレ掃除、そろそろやらないと」
「換気扇の掃除、忘れてた！」

掃除は「やらなきゃ」と思っていても、つい忘れがち。特に週1回、月1回といった定期的な掃除は、気づいたら期限を過ぎていることが多いですよね。

掃除リマインダーBotを作りました

そんな悩みを解決するために、掃除リマインダーLINE Botを作りました。

このBotは、掃除タスクごとに「何日ごとにやるか」を設定でき、期限が来たらLINEで通知してくれます。

主な機能

タスク登録: 「掃除機 7日」「トイレ 3日」など、タスクと間隔を設定
完了報告: 掃除が終わったらLINEで報告するだけ
リマインド通知: 設定した曜日・時間に期限切れタスクを通知
一時停止: 旅行中などはタスクを停止できる

使い方

1. 友だち追加

以下のQRコードまたはリンクから友だち追加してください。

友だち追加はこちら

2. タスクを追加する

1

追加 掃除機 7

これで「7日ごとに掃除機」というタスクが登録されます。

3. 掃除が終わったら報告

1

完了 掃除機

タスクの期限がリセットされ、次の通知まで7日間になります。

4. 残りのタスクを確認

1

残り

期限切れのタスクが一覧で表示されます。何日超過しているかも分かります。

1
2
3


タスクは以下の通りです。
掃除機 (+3日)
トイレ (+1日)

5. 通知設定

好きな曜日と時間に通知を受け取れます。

1

通知設定 月水金 7

これで月・水・金の7時に通知が届きます。

コマンド一覧

コマンド	説明	例
追加 [タスク名] [日数]	タスクを追加	追加掃除機 7
完了 [タスク名]	タスクを完了	完了掃除機
削除 [タスク名]	タスクを削除	削除掃除機
停止 [タスク名]	一時停止	停止掃除機
再開 [タスク名]	再開	再開掃除機
残り	期限切れタスク表示
確認	全タスク詳細表示
通知設定 [曜日] [時間]	通知設定	通知設定月水金 7
使い方	ヘルプ表示

なぜ「日数経過」で管理するのか

一般的なTODOアプリは「期日」を設定しますが、掃除は「前回からどれくらい経ったか」で判断することが多いです。

掃除機は「1週間に1回くらい」
トイレは「3日に1回」
換気扇は「月に1回」

このBotは、完了報告をするたびに自動で次の期限が設定されるので、毎回日付を入力する手間がありません。

無料で使えます

このBotは完全無料で利用できます。ぜひお試しください！

友だち追加はこちら

【初心者向け】掃除リマインダーBotの使い方チュートリアル（初心者向け使い方ガイド）
LINE Messaging APIの登録と使い方（LINE Bot開発の基礎）

OpenAI Response APIの使い方まとめ

Wed, 24 Dec 2025 10:00:00 +0900

概要

OpenAIのResponse APIを使ってテキスト生成を行う手順をまとめました。公式ドキュメントの場所、APIキーの取得方法、Pythonからの最小サンプルまでを確認できます。

Response APIとは

Response APIは、テキスト生成やツール呼び出しなどを統一的に扱えるOpenAIのAPIです。単発の問い合わせから、会話形式のやり取りまで幅広く利用できます。

公式ドキュメント

最新の仕様は公式ドキュメントを参照するのが確実です。

Response API リファレンス: https://platform.openai.com/docs/api-reference/responses

APIキーの取得方法

Response APIを利用するにはOpenAIのAPIキーが必要です。以下の手順で取得できます。

OpenAIのダッシュボードにサインインする
API Keysページ（https://platform.openai.com/api-keys）を開く
「Create new secret key」から新しいキーを発行する

取得したキーは環境変数に設定しておくと安全です。

1

export OPENAI_API_KEY="<YOUR_API_KEY>"

Pythonのサンプルコード

Python SDKを使う場合は、まずuvでパッケージをインストールします。

1

uv pip install openai

以下はResponse APIでテキストを生成する最小サンプルです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


from openai import OpenAI

client = OpenAI()

response = client.responses.create(
 model="gpt-4.1-mini",
 input="Response APIの特徴を3行で教えてください。",
)

print(response.output_text)

実行イメージ

1
2
3


Response APIは単発の生成にも対話にも使える統一APIです。
シンプルなリクエストでモデル出力を取得できます。
公式ドキュメントを確認しながら用途に合わせて拡張できます。

まとめ

Response APIはシンプルな入力でテキスト生成を行えるOpenAIのAPIです。公式ドキュメントを確認し、APIキーを準備してからPythonで試すとスムーズに導入できます。

ChatGPT 4oの紹介（ChatGPTの最新機能紹介）
GCSとGemini File Search APIを自動同期するイベント駆動バックエンドの設計（API統合パターンの実践例）

Codex CLIの使い方まとめ

Fri, 12 Dec 2025 10:00:00 +0900

概要

Codex CLIを使ってローカル環境からコマンドライン経由でCodexにアクセスする手順をまとめました。インストールからサインイン、代表的なコマンドの使い方まで一通り確認できます。

Codex CLIのインストール方法

Node.jsが入っている環境ならnpm経由で簡単に導入できます。

1

npm install -g codex-cli

Homebrewを利用している場合は以下でもOKです。

1
2


brew tap codexcli/tap
brew install codex

インストール後、バージョンが表示されれば準備完了です。

1

codex --version

サインインの方法

Codex CLIは初回実行時に認証が必要です。用途に応じてAPIキーかChatGPTアカウントでサインインできます。

APIキーでサインインする

1

codex login --token <YOUR_API_KEY>

環境変数に設定しておくと毎回入力する手間を省けます。

1

export CODEX_API_KEY=<YOUR_API_KEY>

ChatGPTのアカウントでサインインする

ブラウザでの認証フローを利用したい場合は、トークン指定を省いて codex login を実行します。

1

codex login

上記を実行するとブラウザが開き、ChatGPTのサインイン画面が表示されます。メールアドレスやGoogle/Appleアカウントでサインインし、許可を与えるとCLIに戻ってトークンが保存されます。

サインイン後は共通で以下を実行し、アカウント情報が表示されれば認証成功です。

1

codex whoami

Codexの実行方法とサンプル

単発でコード生成を行う

1

codex run "PythonでFizzBuzzを書いて"

ファイルをコンテキストに含めて要約する

1

codex run "このファイルを要約して" --file README.md

対話モードで試す

1

codex chat

チャットモードでは、プロンプトを入力すると逐次回答が返ってきます。Ctrl + D で終了できます。

チャット内のスラッシュコマンド

対話モードでは先頭に / を付けて補助操作を行えます。

コマンド	役割
`/help`	利用可能なコマンド一覧を表示する
`/new`	会話履歴をリセットして新しいスレッドを開始する
`/file <path>`	指定したファイルをコンテキストに添付する
`/exit`	チャットを終了する

コマンドの使い方

主なコマンドは以下の通りです。

コマンド	説明
`codex login --token <API_KEY>`	APIキーでサインインする
`codex login`	ChatGPTのアカウントでブラウザ認証を開始する
`codex whoami`	現在サインインしているアカウントを確認する
`codex run "<prompt>"`	単発のプロンプトを投げて結果を取得する
`codex run "<prompt>" --file <path>`	ファイルをコンテキストに含めて実行する
`codex chat`	対話モードで利用する
`codex history`	直近の実行履歴を確認する

まとめ

Codex CLIはインストール後にサインインを済ませるだけで、コマンドラインからすぐにCodexを活用できます。よく使うコマンドを覚えておくと、スクリプト生成やファイル要約が素早く行えるようになります。

RedisをGoで使う方法

Sun, 05 Oct 2025 20:25:02 +0900

概要

この記事では、GoでRedisを使う方法について説明します。

Redisの起動方法

Redisの説明やDockerでの起動方法については、こちらの記事を参照してください。

Redisを起動する。

1
2
3


docker run -d --name my-redis \
 -p 6379:6379 \
 redis:7.4.5-alpine

redis-cliで接続確認。

1

docker exec -it my-redis redis-cli ping

PONGと返ってくればOK。

Goのプロジェクトの作成

Goのプロジェクトを作成する。

1
2
3


mkdir redis-go
cd redis-go
go mod init redis-go

GoでRedisを使う

Redisに接続して、書き込み・読み込みを行うサンプルコード。

 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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50


package main

import (
 "context"
 "fmt"
 "log"
 "time"

 "github.com/redis/go-redis/v9"
)

func main() {
 // パスワードなし、ローカルの6379に接続
 rdb := redis.NewClient(&redis.Options{
 Addr: "127.0.0.1:6379",
 Password: "", // なし
 DB: 0,
 DialTimeout: 3 * time.Second,
 ReadTimeout: 1 * time.Second,
 WriteTimeout: 1 * time.Second,
 })
 defer rdb.Close()

 ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
 defer cancel()

 // 接続確認
 if err := rdb.Ping(ctx).Err(); err != nil {
 log.Fatalf("redis ping failed: %v", err)
 }
 log.Println("connected to redis ✅")

 // 基本操作（SET/GET）
 if err := rdb.Set(ctx, "hello", "world", 10*time.Minute).Err(); err != nil {
 log.Fatalf("SET error: %v", err)
 }
 val, err := rdb.Get(ctx, "hello").Result()
 if err != nil {
 log.Fatalf("GET error: %v", err)
 }
 fmt.Println("hello =", val)

 // Set型の例
 key := "team:dev"
 if err := rdb.SAdd(ctx, key, "alice", "bob", "alice").Err(); err != nil {
 log.Fatalf("SADD error: %v", err)
 }
 members, _ := rdb.SMembers(ctx, key).Result()
 fmt.Println("members =", members)
}

パッケージのインストールを行う。

1

go mod tidy

実行する。

1

go run main.go

以下のように表示されればOK。

1
2


hello = world
members = [alice bob]

まとめ

GoでRedisを使う方法について説明しました。 GoでRedisを使う場合は、go-redisを使用します。

RedisをDockerで起動する方法（Redisの起動方法）
macでGoの開発環境を構築して最速でHello Worldする（Go環境構築）

RedisをDockerで起動する方法

Fri, 03 Oct 2025 07:29:31 +0900

概要

この記事では、RedisをDockerで起動する方法について説明します。

Redisとは

Redisは、オープンソースのインメモリデータ構造ストアであり、データベース、キャッシュ、メッセージブローカーとして使用されます。高速な読み書き性能を持ち、様々なデータ構造（文字列、リスト、セット、ハッシュなど）をサポートしています。

DockerでのRedis起動

1. Dockerのインストール

まず、Dockerがインストールされていることを確認します。インストールされていない場合は、Dockerの公式サイトからインストールしてください。

2. Redisコンテナの起動

以下のコマンドを実行して、Redisコンテナを起動します。

1

docker run --name redis -d -p 6379:6379 redis:7.4.5-alpine

コンテナにログインする

1

docker exec -it redis sh

3. Redisの動作確認

Redisコンテナ内で以下のコマンドを実行して、Redisクライアントを起動します。

1

redis-cli

データの設定と取得を試してみます。

1
2
3


set name "hoge"
get name
"hoge"

これで、Redisが正常に動作していることが確認できました。

4. Redisコンテナの停止と削除

Redisコンテナを停止するには、以下のコマンドを実行します。

1

docker stop redis

Redisコンテナを削除するには、以下のコマンドを実行します。

1

docker rm redis

まとめ

この記事では、Dockerを使用してRedisを起動する方法について説明しました。 Redisは高速なデータベースとして広く利用されており、Dockerを使用することで簡単にセットアップできます。ぜひ、Redisを活用してみてください。

RedisをGoで使う方法（GoでRedisを操作する実践例）

Visual Studio CodeでAWS Toolkitを使う方法

Mon, 11 Aug 2025 20:33:30 +0900

概要

この記事では、Visual Studio Code (VSCode) で AWS Toolkit を使用する方法について説明します。

AWS Toolkitのインストール

VSCodeを起動します。
左側のサイドバーから拡張機能アイコンをクリックします。
検索バーに「AWS Toolkit」と入力し、表示されたリストから「AWS Toolkit for Visual Studio Code」を選択します。
「インストール」ボタンをクリックして、インストールを開始します。

Asia Pacific Tokyoリージョンを設定する方法

EXPLORERからリージョンをして利用するのですが、デフォルトではus-east-1が選択されているため、Asia Pacific Tokyoリージョンを設定する必要があります。少しわかりにくいので、以下の手順で設定します。

左側のサイドバーから「AWS Explorer」から、ハンバーガーメニューをクリックします。

Show or Hide Regionsをクリックします。
表示されたリストから「Asia Pacific (Tokyo) ap-northeast-1」を選択します。

これで、AWS ToolkitがAsia Pacific Tokyoリージョンで使用できるようになります。

Visual Studio Codeのアップデート方法

Sun, 27 Jul 2025 18:12:16 +0900

概要

MacでVisual Studio Code（VSCode）のアップデート方法を説明します。 GUIからの手動アップデートに加え、コマンドラインでの更新方法や自動アップデートの設定についても解説します。

GUIからアップデートする方法

VSCodeを起動します。
Code → 「更新の確認」を選択します。英語の場合は Code → “Check for Updates” を選択します。

更新が始まると以下のような画面になります。

ダウンロードが完了すると「再起動して更新」が表示されます。

再起動後「Visual Studio Codeのバージョン情報」をクリックして、バージョンが上がっていることを確認します。

コマンドラインからアップデートする方法

Homebrewを使ってVSCodeをインストールしている場合は、ターミナルからアップデートできます。

現在のバージョンを確認

1

code --version

Homebrewでアップデート

1

brew upgrade --cask visual-studio-code

Homebrewでインストールしていない場合は、既存のVSCodeをアプリケーションフォルダから削除した上で、以下のコマンドでHomebrewによる管理に切り替えられます。設定やインストール済みの拡張機能はアカウント同期で復元できるため、削除しても問題ありません。

1

brew install --cask visual-studio-code

以降は brew upgrade --cask visual-studio-code でアップデートが可能になります。

自動アップデートの設定

VSCodeにはアップデートの挙動を制御する update.mode 設定があります。設定画面を開き（Cmd + ,）、update mode で検索すると変更できます。

設定値	挙動
`default`	バックグラウンドで自動的にアップデートをダウンロード・インストールします
`manual`	アップデートの確認は行いますが、インストールは手動で行います
`start`	VSCodeの起動時のみアップデートを確認します
`none`	自動アップデートを完全に無効化します

settings.jsonで直接設定する場合は以下のように記述します。

1
2
3


{
 "update.mode": "default"
}

特別な理由がない限り default のままで問題ありません。

トラブルシューティング

アップデートが「更新の確認」に表示されない

自動アップデートが無効になっている可能性があります。設定の update.mode が none になっていないか確認してください。

アップデートのダウンロードが失敗する

プロキシやファイアウォールの設定が原因の場合があります。以下の設定を確認してください。

1
2
3
4


{
 "http.proxy": "http://proxy.example.com:8080",
 "http.proxyStrictSSL": false
}

アップデート後に拡張機能が動作しなくなった

拡張機能の互換性の問題が考えられます。以下の手順を試してください。

コマンドパレット（Cmd + Shift + P）を開く
「Extensions: Disable All Installed Extensions」を実行
VSCodeを再起動
拡張機能を1つずつ有効化して問題のある拡張機能を特定する

それでも解決しない場合

VSCodeを再インストールすることで解決する場合があります。

1
2


# Homebrewの場合
brew reinstall --cask visual-studio-code

設定やインストール済みの拡張機能はGitHubアカウントやMicrosoftアカウントで同期しておくと、再インストール後に自動で復元されます。

まとめ

VSCodeのアップデート方法について解説しました。

GUI: Code → 「更新の確認」から数クリックで完了
コマンドライン: brew upgrade --cask visual-studio-code で一括更新
自動アップデート: update.mode 設定で挙動を制御可能

定期的にアップデートを行うことで、新機能やセキュリティパッチを利用できます。アップデート後は、必ずバージョン情報を確認して、正しくアップデートが行われたかをチェックしましょう。

vscodeのインデントガイドをカスタマイズする方法

Tue, 22 Jul 2025 21:01:13 +0900

概要

Visual Studio Code (VSCode) では、インデントガイドの色をカスタマイズすることができます。この記事では、インデントガイドの色を変更する方法を説明します。 indent-rainbowのような拡張機能はインデントガイドが途中で切れるなどの問題がありましたが、VSCodeの設定ファイルを編集するだけで実現できます。

インデントガイドの色を変更する方法

設定ファイルを開く

VSCodeの設定ファイルを開きます。 Command Palette (Ctrl + Shift + P) を開き、Preferences: Open Settings (JSON) を選択します。

設定を追加する

以下を参考に設定を追加します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


{
 "workbench.colorCustomizations": {
 "editorIndentGuide.background1": "#006400",
 "editorIndentGuide.background2": "#008000",
 "editorIndentGuide.background3": "#00a000",
 "editorIndentGuide.background4": "#006400",
 "editorIndentGuide.background5": "#008000",
 "editorIndentGuide.background6": "#00a000",
 "editorIndentGuide.activeBackground1": "#00ff00",
 "editorIndentGuide.activeBackground2": "#00ff00",
 "editorIndentGuide.activeBackground3": "#00ff00",
 "editorIndentGuide.activeBackground4": "#00ff00",
 "editorIndentGuide.activeBackground5": "#00ff00",
 "editorIndentGuide.activeBackground6": "#00ff00",
 "editorWhitespace.foreground": "#393A3D"
 },
}

設定内容	説明
`editorIndentGuide.background<number>`	インデントガイドの背景色を指定します。 `<number>` はインデントの深さに対応します。
`editorIndentGuide.activeBackground<number>`	アクティブなインデントガイドの背景色を指定します。 `<number>` はインデントの深さに対応します。
`editorWhitespace.foreground`	空白文字の色を指定します。

実際に設定を追加した結果以下の画像のようにインデントガイドの色が変更されます。

まとめ

VSCodeでは、インデントガイドの色を簡単にカスタマイズできます。設定ファイルに必要な項目を追加するだけで、好みの色に変更できます。これにより、コードの可読性が向上し、インデントの深さを視覚的に把握しやすくなります。ぜひ試してみてください。

JetBrains製品のメジャーバージョンを上げる方法

Thu, 12 Jun 2025 20:46:53 +0900

概要

IntelliJやPyCharmなどの JetBrains製品のメジャーバージョンを上げる際にサイドダウンロードするが必要になります。設定を引き継ぎつつなるべく簡単にアップデートする方法について説明します。

JetBrains Toolbox Appのインストール

JetBrains製品のメジャーバージョンを上げる際は、JetBrains Toolbox Appを利用することをおすすめします。

上記リンクよりJetBrains Toolbox Appをダウンロードし、インストールします。

アップデート

JetBrains Toolbox Appを起動し、アップデートしたい製品を選択します。

今回はPyCharmをの更新を行うのでクリックすると、アップデートが開始されます。

アップデートが完了すると、以下のように新しいバージョンがインストールされます。

まとめ

JetBrains製品のメジャーバージョンを上げる際は、JetBrains Toolbox Appを利用することで簡単にアップデートが可能です。

FeastのチュートリアルをMacで実行する

Mon, 13 Jan 2025 11:49:53 +0900

概要

今回はFeastのチュートリアルを参考に、Macで実行してみます。

事前準備

MacでUVを用いてPythonの開発環境を構築するを参考にUVを用いて開発できる環境を整えてください。

uvで構築した環境にfeastをインストールする。

FeastのインストールからUIの起動まで

1

> uv pip install feast==0.40.1

2025/01/13現在、Feastにバグがあり最新版をインストールするとUIが起動しないので注意してください。(issue)

Feature Repositoryを作成する。

1
2
3


> feast init my_feature_repo

Creating a new Feast repository in /Users/kouhei/Program/ML/feast/my_feature_repo.

以下のようなリポジトリが作成される。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


> tree
.
└── my_feature_repo
 ├── README.md
 ├── __init__.py
 └── feature_repo
 ├── __init__.py
 ├── data
 │ └── driver_stats.parquet
 ├── example_repo.py
 ├── feature_store.yaml
 └── test_workflow.py

Feastのチュートリアルの設定を反映する。

1
2


cd my_feature_repo/feature_repo
feast apply

Feastのuiを起動する。

1

> feast ui

http://0.0.0.0:8888/p/my_feature_repo へアクセスするとUIが表示されます。

Feastへのデータ操作

5.Build a training datasetからは jupyter notebookを使うのでインストールしておきます。

1

uv pip install jupyter

notebookの起動

1

jupyter notebook

Jupyter Notebookで以下の内容を実行し、トレーニングに利用するデータセットを準備する。

 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


from feast import FeatureStore
import pandas as pd
from datetime import datetime

entity_df = pd.DataFrame.from_dict({
 "driver_id": [1001, 1002, 1003, 1004],
 "event_timestamp": [
 datetime(2021, 4, 12, 10, 59, 42),
 datetime(2021, 4, 12, 8, 12, 10),
 datetime(2021, 4, 12, 16, 40, 26),
 datetime(2021, 4, 12, 15, 1 , 12)
 ]
})

store = FeatureStore(repo_path=".")

training_df = store.get_historical_features(
 entity_df=entity_df,
 features = [
 'driver_hourly_stats:conv_rate',
 'driver_hourly_stats:acc_rate',
 'driver_hourly_stats:avg_daily_trips'
 ],
).to_df()

print(training_df.head())

# Train model
# model = ml.fit(training_df)

NoteBookでの実行結果は以下の通りとなります。

オンラインストアにデータを入れる。
サンプルで記載されている feast materialize-incremental $CURRENT_TIME ではうまく動作しなかったので、データ全体を対象とするように時刻の範囲を設定しています。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


feast materialize 1970-01-01T00:00:00Z 2025-01-04T01:24:24Z

01/04/2025 10:28:40 AM root WARNING: _list_feature_views will make breaking changes. Please use _list_batch_feature_views instead. _list_feature_views will behave like _list_all_feature_views in the future.
Materializing 2 feature views from 1970-01-01 09:00:00+09:00 to 2025-01-04 10:24:24+09:00 into the sqlite online store.

driver_hourly_stats_fresh:
 0%| | 0/5 [00:00<?, ?it/s]01/04/2025 10:28:40 AM root WARNING: Cannot use sqlite_vec for vector search
100%|███████████████████████████████████████████████████████████████| 5/5 [00:00<00:00, 1299.11it/s]
driver_hourly_stats:
100%|███████████████████████████████████████████████████████████████| 5/5 [00:00<00:00, 4569.95it/s]

Jupyter Notebookを用いてオンラインストアからデータを取得します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


from pprint import pprint
from feast import FeatureStore

store = FeatureStore(repo_path=".")

feature_vector = store.get_online_features(
 features=[
 'driver_hourly_stats:conv_rate',
 'driver_hourly_stats:acc_rate',
 'driver_hourly_stats:avg_daily_trips'
 ],
 entity_rows=[{"driver_id": 1001}]
).to_dict()

pprint(feature_vector)

# Make prediction
# model.predict(feature_vector)

出力結果

1
2
3
4


{'acc_rate': [0.5004482269287109],
 'avg_daily_trips': [691],
 'conv_rate': [0.3067885637283325],
 'driver_id': [1001]}

Feastのオンラインストアにマテリアラズして、オンラインストアからデータを取得することができました。

まとめ

本記事では、Feastのチュートリアルを基に、Mac上でFeastを使用してデータを管理する方法を紹介しました。UVを使ったPython開発環境の構築から、Feastのインストール、UIの起動、そしてトレーニングデータの準備やオンラインストアへのデータマテリアライズまで、一連の操作を丁寧に解説しました。これにより、Feastを利用してトレーニングデータと推論データの管理を効率的に行うことができ、トレーニングスキューの回避が可能になります。

MacでUVを用いてPythonの開発環境を構築する（Python環境構築）
Pyenvとvenvを用いたローカル環境のセットアップ方法（従来のPython環境構築方法）
macでparquetファイルを読む方法（Feastのサンプルデータ形式）

MacでUVを用いてPythonの開発環境を構築する

Wed, 01 Jan 2025 14:39:53 +0900

概要

MacでPythonの開発環境を構築する方法を紹介します。

uvとは

2024年中旬に発表されたばかりのパッケージ管理ツール。
Rustで書かれており、他のパッケージ管理マネージャよりも高速であることが特徴です。

公式の説明はこちらを参照してください。

利用方法

uvのインストール

1

curl -LsSf https://astral.sh/uv/install.sh | sh

PATHを通す

1
2


source $HOME/.local/bin/env (sh, bash, zsh)
source $HOME/.local/bin/env.fish (fish)

インストールできたことを確認

1
2


uv --version
uv 0.5.13 (c456bae5e 2024-12-27)

使い方

仮想環境の作成

1

uv venv

仮想環境のアクティベート

1

source .venv/bin/activate

パッケージのインストール

1

uv pip install <package name>

uvの細かい説明は公式のドキュメントを参照してください。

まとめ

MacでPythonの開発環境を構築する方法を紹介しました。 uvは高速かつ使いやすいので2025年1月時点ではPythonの開発環境構築において有用なツールと言えるでしょう。

Pyenvとvenvを用いたローカル環境のセットアップ方法（従来のPython環境構築方法）

セレモニーの見直しによるチームパフォーマンス向上

Mon, 18 Nov 2024 09:36:05 +0900

概要

Scrumを採用しているチームでは、セレモニーを行います。セレモニーはチームメンバーが集まり、スプリントの進捗や課題を共有し、次のスプリントに向けての計画を立てるための重要な場です。しかし、Scrumを惰性で続けてしまっているとセレモニーが長引いたり、効果的な議論が行われなかったりすることがあります。

この記事では、セレモニーの見直しによってチームのパフォーマンスを向上させる方法について考察します。

セレモニーの目的を明らかにする

各セレモニーの目的は以下の通りです。
もっとも大切なことはこの目的を達成するために必要な議論がなされるアジェンダになっていることです。目的についてはスクラムガイドを参考に記載していますが、やや筆者の意訳が含まれています。

セレモニー	目的
デイリースクラム	スプリントゴールを達成するために、チームの一日の計画を立てる。
スプリントレビュー	スプリントの成果を検査し、今後の適応を決定すること。
プロダクトバックログリファインメント	プロダクトバックログを整理し、プロダクトゴールを達成するための計画を立てる。
スプリントレトロスペクティブ	スプリントの振り返りを行い、品質と高価を高めるための適応を計画もしくは実行する。
スプリントプランニング	次のスプリント期間中の作業計画を立てる

タイムボックスの徹底

セレモニーを効率的に行うためには、タイムボックスを徹底することが重要です。タイムボックスとは、セレモニーの時間を決めてその時間内に議論を終えるというルールのことです。

セレモニーではタイムボックスを超えないようにし、超えてしまった場合はなぜ超えてしまったのか、超えないようにはどうしていくと良いのかを振り返ることが重要です。

セレモニーごとの効率的な議論を行うためのポイント

セレモニーのうち特に時間を取られがちなものについて、効率的な議論を行うためのポイントを以下に示します。

デイリースクラム

デイリースクラムではチームが今日何をするべきかが明確になるようにすることに主眼を置きます。
それ以外の議論や報告についてはデイリースクラムとは呼ばずに関係者を絞り別途時間を設けるようにします。
チームメンバー全員の時間を使って行う価値があるかどうかを常に意識することが重要です。

ポイント

15分を超えないようにする
報告内容を絞る
議論が発生する場合は、別途時間を設け議論を行うというルールにする

スプリントレビュー

スプリントレビューではステークホルダーに対してフィードバックをもらい、次のスプリントに向けての計画を立てるための情報を得ることが目的です。漫然とインクリメントを見せるだけではなく、事前にフィードバックを得たい内容を明確にしておくことが重要です。

ポイント

レビューの準備を事前に行う
誰に、どのようなフィードバック得たいのか事前に明らかにしておく（仮説を立てる）

プロダクトバックログリファインメント

プロダクトバックログリファインメントは一般的には最大でスプリントの10%程度の時間を割くことが推奨されています。
特に見積もりに時間がかかることが多いのである程度見切りをつけて行うことが大切です。

ポイント

バックログアイテムに対する詳細な議論をしすぎない。
- 次スプリント以降のアイテムはすぐにやらない可能性もあるので、詳細な議論は不要です。スプリント計画のタイミングで実施しましょう。
見積もりについては相対見積もりを採用し、細かい数値にこだわらない
- 不確実性のコーンコーンが示す通り、見積もりは基本的にはブレるものであり、細かい数値にこだわる必要はありません。

まとめ

今回はセレモニーを効率的に進める方法について説明しました。
セレモニーを効率的に進めることで、チームのパフォーマンスを向上させることができます。

macでGoの開発環境を構築して最速でHello Worldする

Sun, 15 Sep 2024 16:52:04 +0900

概要

MacでGo言語の開発環境を構築して、最速で Hello World する方法を紹介します。

Go言語のインストール

brewを使ってGo言語をインストールします。

1

> brew install go

バージョンを確認

1
2


> go version
go version go1.21.3 darwin/arm64

Hello World の実行

以下のコードを main.go として保存します。

1
2
3
4
5
6
7


package main

import "fmt"

func main() {
 fmt.Printf("Hello World\n")
}

実行する

1
2


> go run hello.go
Hello World

バイナリをビルドして実行する

1
2
3
4
5
6
7


> go build hello.go

> ls
hello* hello.go

> ./hello
Hello World

まとめ

以上で、MacでGo言語の開発環境を構築して、最速で Hello World する方法を紹介しました。

gRPCについての調査（gRPCの実践）
RedisをGoで使う方法（Redis + Goの実践）

macでparquetファイルを読む方法

Sun, 15 Sep 2024 16:52:04 +0900

概要

macでparquetファイルをコマンドラインで簡単に読む方法を紹介します。

parquet-cliを使って読む

今回は Feastのサンプルで提供されているParquetファイルを読んでみます。

parquet-cliをbrewでmacにインストールする。

1

brew install parquet-cli

meta情報を確認する。

 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


$ parquet meta driver_stats.parquet

File path: driver_stats.parquet
Created by: parquet-cpp-arrow version 18.1.0
Properties:
 pandas: {"index_columns": [{"kind": "range", "name": null, "start": 0, "stop": 1807, "step": 1}], "column_indexes": [{"name": null, "field_name": null, "pandas_type": "unicode", "numpy_type": "object", "metadata": {"encoding": "UTF-8"}}], "columns": [{"name": "event_timestamp", "field_name": "event_timestamp", "pandas_type": "datetimetz", "numpy_type": "datetime64[ns]", "metadata": {"timezone": "UTC"}}, {"name": "driver_id", "field_name": "driver_id", "pandas_type": "int64", "numpy_type": "int64", "metadata": null}, {"name": "conv_rate", "field_name": "conv_rate", "pandas_type": "float32", "numpy_type": "float32", "metadata": null}, {"name": "acc_rate", "field_name": "acc_rate", "pandas_type": "float32", "numpy_type": "float32", "metadata": null}, {"name": "avg_daily_trips", "field_name": "avg_daily_trips", "pandas_type": "int32", "numpy_type": "int32", "metadata": null}, {"name": "created", "field_name": "created", "pandas_type": "datetime", "numpy_type": "datetime64[us]", "metadata": null}], "creator": {"library": "pyarrow", "version": "18.1.0"}, "pandas_version": "2.2.3"}
 ARROW:schema: /////xgGAAAQAAAAAAAKAA4ABgAFAAgACgAAAAABBAAQAAAAAAAKAAwAAAAEAAgACgAAAHAEAAAEAAAAAQAAAAwAAAAIAAwABAAIAAgAAABIBAAABAAAADsEAAB7ImluZGV4X2NvbHVtbnMiOiBbeyJraW5kIjogInJhbmdlIiwgIm5hbWUiOiBudWxsLCAic3RhcnQiOiAwLCAic3RvcCI6IDE4MDcsICJzdGVwIjogMX1dLCAiY29sdW1uX2luZGV4ZXMiOiBbeyJuYW1lIjogbnVsbCwgImZpZWxkX25hbWUiOiBudWxsLCAicGFuZGFzX3R5cGUiOiAidW5pY29kZSIsICJudW1weV90eXBlIjogIm9iamVjdCIsICJtZXRhZGF0YSI6IHsiZW5jb2RpbmciOiAiVVRGLTgifX1dLCAiY29sdW1ucyI6IFt7Im5hbWUiOiAiZXZlbnRfdGltZXN0YW1wIiwgImZpZWxkX25hbWUiOiAiZXZlbnRfdGltZXN0YW1wIiwgInBhbmRhc190eXBlIjogImRhdGV0aW1ldHoiLCAibnVtcHlfdHlwZSI6ICJkYXRldGltZTY0W25zXSIsICJtZXRhZGF0YSI6IHsidGltZXpvbmUiOiAiVVRDIn19LCB7Im5hbWUiOiAiZHJpdmVyX2lkIiwgImZpZWxkX25hbWUiOiAiZHJpdmVyX2lkIiwgInBhbmRhc190eXBlIjogImludDY0IiwgIm51bXB5X3R5cGUiOiAiaW50NjQiLCAibWV0YWRhdGEiOiBudWxsfSwgeyJuYW1lIjogImNvbnZfcmF0ZSIsICJmaWVsZF9uYW1lIjogImNvbnZfcmF0ZSIsICJwYW5kYXNfdHlwZSI6ICJmbG9hdDMyIiwgIm51bXB5X3R5cGUiOiAiZmxvYXQzMiIsICJtZXRhZGF0YSI6IG51bGx9LCB7Im5hbWUiOiAiYWNjX3JhdGUiLCAiZmllbGRfbmFtZSI6ICJhY2NfcmF0ZSIsICJwYW5kYXNfdHlwZSI6ICJmbG9hdDMyIiwgIm51bXB5X3R5cGUiOiAiZmxvYXQzMiIsICJtZXRhZGF0YSI6IG51bGx9LCB7Im5hbWUiOiAiYXZnX2RhaWx5X3RyaXBzIiwgImZpZWxkX25hbWUiOiAiYXZnX2RhaWx5X3RyaXBzIiwgInBhbmRhc190eXBlIjogImludDMyIiwgIm51bXB5X3R5cGUiOiAiaW50MzIiLCAibWV0YWRhdGEiOiBudWxsfSwgeyJuYW1lIjogImNyZWF0ZWQiLCAiZmllbGRfbmFtZSI6ICJjcmVhdGVkIiwgInBhbmRhc190eXBlIjogImRhdGV0aW1lIiwgIm51bXB5X3R5cGUiOiAiZGF0ZXRpbWU2NFt1c10iLCAibWV0YWRhdGEiOiBudWxsfV0sICJjcmVhdG9yIjogeyJsaWJyYXJ5IjogInB5YXJyb3ciLCAidmVyc2lvbiI6ICIxOC4xLjAifSwgInBhbmRhc192ZXJzaW9uIjogIjIuMi4zIn0ABgAAAHBhbmRhcwAABgAAACwBAADcAAAApAAAAHAAAAA0AAAABAAAAPz+//8AAAEKEAAAABgAAAAEAAAAAAAAAAcAAABjcmVhdGVkAGr///8AAAIAKP///wAAAQIQAAAAIAAAAAQAAAAAAAAADwAAAGF2Z19kYWlseV90cmlwcwBo////AAAAASAAAABg////AAABAxAAAAAcAAAABAAAAAAAAAAIAAAAYWNjX3JhdGUAAAAA0v///wAAAQCQ////AAABAxAAAAAgAAAABAAAAAAAAAAJAAAAY29udl9yYXRlAAYACAAGAAYAAAAAAAEAxP///wAAAQIQAAAAJAAAAAQAAAAAAAAACQAAAGRyaXZlcl9pZAAAAAgADAAIAAcACAAAAAAAAAFAAAAAEAAUAAgABgAHAAwAAAAQABAAAAAAAAEKEAAAACgAAAAEAAAAAAAAAA8AAABldmVudF90aW1lc3RhbXAACAAMAAYACAAIAAAAAAADAAQAAAADAAAAVVRDAAAAAAA=
Schema:
message schema {
 optional int64 event_timestamp (TIMESTAMP(NANOS,true));
 optional int64 driver_id;
 optional float conv_rate;
 optional float acc_rate;
 optional int32 avg_daily_trips;
 optional int64 created (TIMESTAMP(MICROS,false));
}


Row group 0: count: 1807 16.88 B records start: 4 total(compressed): 29.796 kB total(uncompressed):29.760 kB
--------------------------------------------------------------------------------
 type encodings count avg size nulls min / max
event_timestamp INT64 S _ R 1807 2.78 B 0 "2021-04-12T07:00:00.00000..." / "2024-12-28T14:00:00.00000..."
driver_id INT64 S _ R 1807 0.07 B 0 "1001" / "1005"
conv_rate FLOAT S _ R 1807 5.42 B 0 "1.9221554E-4" / "0.9998668"
acc_rate FLOAT S _ R 1807 5.42 B 0 "2.1329636E-4" / "0.99993944"
avg_daily_trips INT32 S _ R 1807 3.14 B 0 "0" / "999"
created INT64 S _ R 1807 0.05 B 0 "2024-12-28T15:20:28.266000" / "2024-12-28T15:20:28.266000"

headで中を見る。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


$ parquet head driver_stats.parquet

{"event_timestamp": 1734102000000000000, "driver_id": 1005, "conv_rate": 0.27734742, "acc_rate": 0.7152132, "avg_daily_trips": 823, "created": 1735399228266000}
{"event_timestamp": 1734105600000000000, "driver_id": 1005, "conv_rate": 0.57354224, "acc_rate": 0.9831811, "avg_daily_trips": 851, "created": 1735399228266000}
{"event_timestamp": 1734109200000000000, "driver_id": 1005, "conv_rate": 0.3287562, "acc_rate": 0.6172164, "avg_daily_trips": 116, "created": 1735399228266000}
{"event_timestamp": 1734112800000000000, "driver_id": 1005, "conv_rate": 0.045716193, "acc_rate": 0.032996926, "avg_daily_trips": 741, "created": 1735399228266000}
{"event_timestamp": 1734116400000000000, "driver_id": 1005, "conv_rate": 0.12863782, "acc_rate": 0.8951942, "avg_daily_trips": 534, "created": 1735399228266000}
{"event_timestamp": 1734120000000000000, "driver_id": 1005, "conv_rate": 0.9555806, "acc_rate": 0.62216556, "avg_daily_trips": 216, "created": 1735399228266000}
{"event_timestamp": 1734123600000000000, "driver_id": 1005, "conv_rate": 0.75297666, "acc_rate": 0.37602386, "avg_daily_trips": 954, "created": 1735399228266000}
{"event_timestamp": 1734127200000000000, "driver_id": 1005, "conv_rate": 0.46957988, "acc_rate": 0.6454945, "avg_daily_trips": 360, "created": 1735399228266000}
{"event_timestamp": 1734130800000000000, "driver_id": 1005, "conv_rate": 0.6702387, "acc_rate": 0.36532214, "avg_daily_trips": 396, "created": 1735399228266000}
{"event_timestamp": 1734134400000000000, "driver_id": 1005, "conv_rate": 0.019627139, "acc_rate": 0.528229, "avg_daily_trips": 833, "created": 1735399228266000}

スキーマの確認。

 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
32
33


$ parquet schema driver_stats.parquet
{
 "type" : "record",
 "name" : "schema",
 "fields" : [ {
 "name" : "event_timestamp",
 "type" : [ "null", "long" ],
 "default" : null
 }, {
 "name" : "driver_id",
 "type" : [ "null", "long" ],
 "default" : null
 }, {
 "name" : "conv_rate",
 "type" : [ "null", "float" ],
 "default" : null
 }, {
 "name" : "acc_rate",
 "type" : [ "null", "float" ],
 "default" : null
 }, {
 "name" : "avg_daily_trips",
 "type" : [ "null", "int" ],
 "default" : null
 }, {
 "name" : "created",
 "type" : [ "null", {
 "type" : "long",
 "logicalType" : "local-timestamp-micros"
 } ],
 "default" : null
 } ]
}

まとめ

macでparquetファイルを簡単に読む方法を紹介しました。

FeastのチュートリアルをMacで実行する（Parquetファイルを使ったFeastの活用）

共分散についての調査

Mon, 02 Sep 2024 10:00:00 +0900

共分散とは

共分散は、2つの変数がどのように連動して変化するかを示す統計量です。
正の値なら同じ方向に変化しやすく、負の値なら逆方向に変化しやすいことを意味します。

計算式

共分散は次の式で計算されます：

ポイント

共分散が 0 に近い場合、2つの変数に強い関係はないと考えられます。
値がスケールに依存するため、相関係数を使うことが一般的です。

Pythonでの例

以下は、Pythonを使った共分散の計算例です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


import numpy as np

# サンプルデータ
X = [2.1, 2.5, 4.0, 3.6]
Y = [8, 10, 12, 14]

# 共分散の計算
cov_matrix = np.cov(X, Y, bias=True)
covariance = cov_matrix[0][1]

print(f"共分散: {covariance}")

実行結果

1

共分散: 1.53

共分散と相関係数の違い

特徴	共分散	相関係数
スケール依存	あり	なし
値の範囲	-∞ から ∞	-1 から 1\

まとめ

共分散は、2つの変数の関係性を理解するための基本的な指標です。
ただし、スケール依存性があるため、相関係数と併用することでより深い分析が可能です。

gRPCについての調査

Sun, 01 Sep 2024 17:53:57 +0900

gRPCとは

PRCを実現するためにGoogleが開発したプロトコルの一つ
Protocol Bufferを使ってデータをシリアライズし、高速な通信を実現できる点が特徴
IDLを使ってあらかじめAPIの仕様を.protoファイルとして定義し、そこから、サーバ側&クライアント側に必要なソースコードを生成する。

REST と gRPCの違い

RESTはリソース志向、RPCはメソッドの呼び出しが起点となり、データは副産物であるという考え方。

利点と欠点

利点

HTTP/2による高パフォーマンス
Protocol Buffersによるデータ転送
- IDLを書くことになるので、スキーマファーストで開発することになる
柔軟なストリーミング方式

欠点

HTTP/2非対応
ブラウザの対応状況が不十分
言語によって機能の実装増強にばらつきがある
バイナリにシリアライズされると人間が読めない
RESTでも十分早い

.protファイル

gRPCではシリアライズフォーマットとしてProtocol Buffersを利用する。
.proto を拡張子として持つファイル上にスキーマ定義を行い、 protoc コマンド絵各言語用のコードを生成する。
Protocol Buffersでは全ての値が型を持つ。型はスカラー型とメッセージ型に分けることができる。

スカラー型

数値、文字列、真偽値、バイト配列

メッセージ型

複数のフィールドを持ったメッセージ型
メッセージ型は一つの .proto ファイルに複数定義することができる

1
2
3
4
5


message Person {
 int32 id = 1;
 string name = 2;
 string email =3;
}

gRPCのQuick Startを実施する

今回はPythonの環境を用いて、gRPCのQuick Startを実施する。
https://grpc.io/docs/languages/python/quickstart/

起動に必要なPythonの環境を整える。

1
2


python -m pip install grpcio
python -m pip install grpcio-tools

サンプルコードのダウンロード

1
2


git clone -b v1.64.0 --depth 1 --shallow-submodules https://github.com/grpc/grpc
cd grpc/examples/python/helloworld

サーバを起動する。

1
2
3
4


python greeter_server.py

# 出力
Server started, listening on 50051

別のターミナルを起動し、クライアントを起動する。

1
2
3
4
5


python greeter_client.py

## レスポンス
Will try to greet world ...
Greeter client received: Hello, you!

gRPCのクライアントとサーバを用いて通信を行うことができました。

.proto ファイルを変更してみる

今回は、helloworld.proto ファイルを変更して、新しいメソッドを追加してみます。

helloworld.prot ファイルが格納されている

1

cd grpc/examples/protos

以下のように修正する

 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


syntax = "proto3";

option java_multiple_files = true;
option java_package = "io.grpc.examples.helloworld";
option java_outer_classname = "HelloWorldProto";
option objc_class_prefix = "HLW";

package helloworld;

// The greeting service definition.
service Greeter {
 // Sends a greeting
 rpc SayHello (HelloRequest) returns (HelloReply) {}

 // 以下の1行を追加
 rpc SayHelloAgain (HelloRequest) returns (HelloReply) {}

 rpc SayHelloStreamReply (HelloRequest) returns (stream HelloReply) {}

 rpc SayHelloBidiStream (stream HelloRequest) returns (stream HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
 string name = 1;
}

// The response message containing the greetings
message HelloReply {
 string message = 1;
}

grpcのコードを生成する

1
2
3


cd examples/python/helloworld

python -m grpc_tools.protoc -I../../protos --python_out=. --pyi_out=. --grpc_python_out=. ../../protos/helloworld.proto

以下のファイルが再作成されている。

1
2
3
4
5


ls -l

-rw-r--r--@ 1 xx xx 1823 9 1 18:12 helloworld_pb2.py
-rw-r--r--@ 1 xx xx 578 9 1 18:12 helloworld_pb2.pyi
-rw-r--r--@ 1 xx xx 7018 9 1 18:12 helloworld_pb2_grpc.py

更新される _pd ファイルとは、protocol Buuffersの定義クラスが自動で生成されており基本的にはさわらない。

greeter_server.py を更新する。

 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


from concurrent import futures
import logging

import grpc
import helloworld_pb2
import helloworld_pb2_grpc


class Greeter(helloworld_pb2_grpc.GreeterServicer):
 def SayHello(self, request, context):
 return helloworld_pb2.HelloReply(message="Hello, %s!" % request.name)
 # 以下の関数を追加
 def SayHelloAgain(self, request, context):
 return helloworld_pb2.HelloReply(message="Hello Again, %s!" % request.name)

def serve():
 port = "50051"
 server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
 helloworld_pb2_grpc.add_GreeterServicer_to_server(Greeter(), server)
 server.add_insecure_port("[::]:" + port)
 server.start()
 print("Server started, listening on " + port)
 server.wait_for_termination()


if __name__ == "__main__":
 logging.basicConfig()
 serve()

greeter_client.py を更新する。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


def run():
 # NOTE(gRPC Python Team): .close() is possible on a channel and should be
 # used in circumstances in which the with statement does not fit the needs
 # of the code.
 print("Will try to greet world ...")
 with grpc.insecure_channel("localhost:50051") as channel:
 stub = helloworld_pb2_grpc.GreeterStub(channel)
 response = stub.SayHello(helloworld_pb2.HelloRequest(name="you"))
 print("Greeter client received: " + response.message)
 response = stub.SayHelloAgain(helloworld_pb2.HelloRequest(name="you"))
 print("Greeter client received: " + response.message)

serverを再起動し、clientを実行する。

1
2
3
4
5
6


python greeter_server.py
python greeter_client.py

# 出力
Greeter client received: Hello, you!
Greeter client received: Hello Again, you!

追加したメソッドが正常に動作していることが確認できました。

まとめ

今回はgRPCについて調査の調査と公式ドキュメントのチュートリアルを行いました。 gRPCはスキーマファーストで開発することができ、HTTP/2による高パフォーマンス通信が可能であることら、最近ではREST APIの代替手段として注目されている技術ですので、ぜひ抑えておきたいです。

macでGoの開発環境を構築して最速でHello Worldする（Go環境構築）

ChatGPT 4oの紹介

Tue, 14 May 2024 23:22:39 +0900

GPT-4oの登場

2024年5月13日に、OpenAI社より新しいGPTモデル、ChatGPT-4oが発表されました。

GPT-4oは従来のモデルと比較して以下の内容が向上しています。

自然な対話の実現
より高速な応答
多言語対応の強化
より高い信頼性

特に注目すべきは、推論速度と質の向上です。これにより、リアルタイムの対話システムにおいても高い性能を発揮し、よりスムーズで自然なコミュニケーションが可能となります。

リアルタイム対話の応用

以下の動画では、スマートフォンを利用してChatGPT-4oとのリアルタイム対話のデモンストレーションが紹介されています。

実際にご覧いただけるとわかるように、ChatGPT-4oは人間との対話に近いレベルで応答を返すことができます。
これにより、ユーザーは非常に自然な対話を楽しむことができます。

今までのChatGPTシリーズでは音声を文字列へ変換し、その後GPT-4へ入力することで対話を行っていました。
これは、音声に含まれる声色などの感情の情報が失われることを意味しています。

しかし、ChatGPT-4oでは音声からモデルのトレーニングを行っているため、声色などの情報も考慮されており、より自然な対話が実現されています。
また、音声から直接音声を返却するので、テキストを解釈するステップがない分より高速に応答が返ってくるようになっています。

多言語対応の強化

GPT-4oは、多言語対応の強化も図っています。
今までは英語で質問をすると、精度が高い回答が得られるが、日本語で質問をすると精度が落ちるという問題がありました。

今回の多言語対応の強化により、日本語でも高い精度で回答が得られるようになりました。

まとめ

今回は、OpenAI社が発表したChatGPT-4oについて紹介しました。
ChatGPTのモデルの精度の向上はめざましく、どんどん人間の対話に近づいていると感じます。
今後エンジニアは生成AIをどれだけうまく使えるかで、生産性が大きく変わってくると感じているので引き続き動向を注視していきたいと思います。

EvernoteからNotionへの移行方法

Mon, 29 Apr 2024 19:32:38 +0900

概要

2024年4月26日にEvernoteの日本法人が解散するなど、Evernoteのサービスは終了しないもののいよいよEvernoteの雲行きが怪しくなってきました。
Evernoteは無料プランに制限が多いため、有料プランを利用しており費用がかさむこともあり、他のノートアプリへの移行を検討しました。

以下の理由から移行先はNotionを選択しました。

ノートアプリととして基本的な機能を揃えており、Evernoteの代替として十分利用できる。
Notionは無料プランの制限がゆるく無料プランで十分使え移行することで有料プランの費用を削減できる。
Evernoteからインポートする機能がNotion側で提供されており、移行コストが非常に低い。

今回はEvernoteからNotionへの移行方法をまとめます。

移行方法

NotionにはEvernoteからのインポート機能が提供されているため、こちらを利用するだけで簡単に移行ができます。

Notionのアプリのメニューから 設定 を選択します。

設定をクリックすると インポート が表示されるので、これをクリックします。
インポートをクリックすると、インポート元のアプリケーションが表示されるので、ここで Evernote を選択します。

連携が完了するとインポートするノートブックが選択できるようになります。

ここでの注意点です！
ノートブックを複数選択すると一気にインポートできるように見えるのですが、一気にインポートするととんでもない時間がかかった挙げ句エラーが出ることがあります。このため、ノートブックは一つづつインポートすることをおすすめします。

一つずつインポートした場合でも、ノートの分量が多いと数時間かかったりするので、気長に対応するとよいです。

インポート後は特に体裁が崩れることもなく、画像やリンク、ラベルも正常にインポートされるので問題なく利用ができました。

まとめ

EvernoteからNotionへの移行方法をまとめました。無料で機能が豊富なNotionに簡単に移行できるので、ぜひ移行を検討してみてください。

グローバルなgitignoreを設定してプロジェクト全体に適応する方法

Tue, 16 Apr 2024 23:16:25 +0900

概要

.gitignore ファイルをプロジェクトに追加することでプロジェクト事にgitのトラッキング対象から外すことができます。
しかしながら.idea などIDEがデフォルトで生成するディレクトリを毎回プロジェクト毎にgitignoreに追加するのが面倒です。
本記事では gitignore に設定した内容をすべてのプロジェクトに適応する方法をまとめます。

gitignoreを全体に適応する方法

gitはデフォルトで ~/.config/git/ignore へignore設定を見に行きます。
このため、~/.config/git/ignore にignore設定を記述することですべてのプロジェクトにgitignoreの内容を適応できます。

よく .gitignore_global を作成して、core.excludesfile に登録する方法が案内されていますが、この方法だと .gitconfig に無駄な設定をいれる必要があるため、こちらの方法をおすすめします。

プロジェクト全体にgitignoreを適応する手順

ignoreファイルを格納するためのディレクトリを作成します。

1

mkdir -p ~/.config/git/

ignoreファイルを作成し、全プロジェクトで無視したい内容を記述してください。

1

vim ~/.config/git/ignore

記載例

1
2
3


.idea/
*.log
node_modules/

この設定を行うことで、全プロジェクトで同じignore設定を適応できます。
すでにトラッキングしているファイルを含む場合は、一度 git rm --cached でトラッキングを解除してください。

参考

Git - gitignore

PythonでBluesky APIを用いて自動投稿する方法

Sun, 07 Apr 2024 23:52:09 +0900

概要

Bluesky とは、旧Twitter社の元CEOであるジャック・ドーシー氏が立ち上げた分散型SNSです。
ATProtocl というプロトコルを用いて構築されたSNSで、簡単に言うと中央管理者がいないTwitterのようなものです。
昨今の中央集権である通貨から分散型である仮想通貨への流れのように、SNSも分散型への流れがあるのかなと感じます。

今回はそんなBlueskyのAPIをPythonを用いて実行する方法をまとめます。

Bluesky APIを使うまでのステップ

API実行用パスワードの生成
Python実行環境の構築
スクリプトの作成と実行

API実行用パスワードの生成

APIを実行するためにはアカウント名とAPI実行用のパスワードの発行が必要です。

まずは、APIの実行に利用するアカウント名を確認します。
アカウント名は、Blueskyにログインした際に画像の箇所に表示される名前となります。
この際先頭の @ は不要で、私のアカウントであれば bossagyu.bsky.social がアカウント名となります。

次に、API実行用のパスワードを生成します。

API実行用パスワードは 設定 → アプリパスワード から生成できます。

その後、アプリパスワードを追加 をクリックします。

追加ボタンを押すと、パスワードにつける名前を聞かれます。
これ自体はパスワードとならず管理を容易にすることが目的なので、特にこだわりがなければそのまま作成します。

パスワードが生成されるので、これをコピーしておきます。
ちなみに二度と表示されなくなるので、コピーを忘れないようにしましょう。コピーを忘れた場合は再生成すればOKです。

Python実行環境の構築

Pythonの実行環境をセットアップしてください。
venvを用いたセットアップについては、こちらにまとめています。

公式ドキュメントによると、Pythonのバージョンは3.7.1以上を利用する必要がありますので注意しておいてください。

Pythonの実行環境が整えば、ATProtocolを利用するためにライブラリをインストールします。

1

$ pip install atproto

インストールの確認

1
2
3


$ pip list | grep atproto

atproto 0.0.46

これで準備は完了です。

スクリプトの作成と実行

Blueskyに投稿するスクリプトを作成します。

1
2
3
4
5
6
7
8
9


from atproto import Client

client = Client()

user_name = "bossagyu.bsky.social"
password = "*******" # 生成したAPI実行用パスワードを入力

client.login(user_name, password)
client.send_post(text='APIからの投稿です')

スクリプトはこれだけで、APIを用いてBlueskyに投稿できます。

それでは実行してみましょう。

1

$ python post_bluesky.py

実行すると、Blueskyに以下のように無事投稿されました。

まとめ

今回はPythonを用いてBlueskyのAPIを実行する方法をまとめました。 Blueskyはまだまだ開発途中のSNSですが、TwitterはAPIを課金しないと使えないなどの制約があるので、無料でAPIを使ってSNSで遊んでみたいという方にはおすすめです。

Pyenvとvenvを用いたローカル環境のセットアップ方法（Python環境構築）
MacでUVを用いてPythonの開発環境を構築する（モダンなPython環境構築）

chatGPTで画像を生成する方法

Sun, 31 Mar 2024 17:35:07 +0900

概要

Stable Diffusionなどの画像生成用のモデルではなく ChatGPTでも画像が生成できるので、生成の方法を説明します。
ChatGPTの有料プランを利用している人は新たに課金などせずに利用できるので、大きな手間をかけずに商用利用可能な画像を生成できます。

今回は、DALL-Eと呼ばれるChatGPT Plusの機能を利用して画像を生成します。 DALL-E3については OpenAI の公式ページを参照してください。

画像生成の方法

サイドバーから「Explore GPTs」を選択

検索窓で DALL-E と入力し検索を行う。

Start Chat をクリックし、画像生成を開始する。

後は、生成したい画像の説明を入力するだけで画像が生成されます。

実際に画像を生成してみる

このブログで利用されている、ピンク色のサングラスを掛けた犬の画像を生成してみます。

とりあえず ピンク色のサングラスをかけた犬 というプロンプトで打ってみます。

また、普段のChat GPTを使うように出力された画像に対して追加のプロンプトを入力することで加工できます。
今回は アニメ調にしてください と追加のプロンプトを入力してみます。

アニメ調になっているのがわかります。このように追加のオーダーをすることでどんどん目的の画像に近づけつつ生成できます。

まとめ

今回はChatGPTを利用して画像を生成する方法を説明しました。

簡単に画像を生成できるのが非常に便利ですが、Stable Diffusion同様期待する画像を出力することはなかなか難しく、プロンプトを調整する必要があります。 Stable Diffusionを利用したときよりもプロンプトを工夫しなくても良い画像が生成されるので、このあたりはモデルの性能差なのかなと思いました。

ちなみに、やりすぎると以下のような文章が出力され、待つように言われるので生成回数には制限がついていそうです。マシンソースがある人はやっぱりローカルmacでStable Diffusionでやるのが良さそうですね。

ChatGPT 4oの紹介（ChatGPT 4oの新機能紹介）

TyeScriptにおけるEnumの使い方

Sat, 23 Mar 2024 13:11:13 +0900

概要

この記事では、TypeScriptにおけるEnumの使い方について説明します。

Enumとは

Enum（列挙型）は、特定の値の集合を表す型です。
多くの言語に実装されていますが、JavaScriptには存在しません。しかし、TypeScriptではEnumがサポートされています。

Enumの使い方

以下のようにEnumを定義します。

1
2
3
4
5
6
7


enum Status {
 zero,
 one,
 two
}

console.log(Status.zero); // 0

Enumは、デフォルトで数値を割り当てられ、0から始まります。生成されるJavaScriptコードは以下の通りです。

1
2
3
4
5
6
7


var Status;
(function (Status) {
 Status[Status["zero"] = 0] = "zero";
 Status[Status["one"] = 1] = "one";
 Status[Status["two"] = 2] = "two";
})(Status || (Status = {}));
console.log(Status.zero); // 0

また、enumの値を文字列で指定することもできます。

1
2
3
4
5
6
7


enum Status {
 zero = 'zero',
 one = 'one',
 two = 'two'
}

console.log(Status.zero); // zero

文字列比較を行う場合は、以下のように記述します。

1
2
3
4
5
6
7
8


const stringZero :String = 'zero';
const value = stringZero as StringStatus;

if (value === StringStatus.zero) {
 console.log('value is zero');
} else {
 console.log('value is not zero');
}

まとめ

この記事では、TypeScriptにおけるEnumの使い方について説明しました。 enumを利用することで、コードの可読性、保守性を向上させることができます。

Voltaを利用してTypeScriptの開発環境を簡単にセットアップする方法（TypeScript環境構築）

Voltaを利用してTypeScriptの開発環境を簡単にセットアップする方法

Sun, 10 Mar 2024 13:11:13 +0900

概要

この記事では、TypeScriptの開発環境を簡単にセットアップする方法について説明します。本記事ではMacOSを対象にしています。

Voltaとは

VoltaはNode.jsのバージョン管理ツールです。
Voltaの公式サイトで紹介されている通り以下の特徴を備えています。

高速
- Rustで構築されており、Node.jsのバージョン切り替えが高速です。
信頼できる
- プロジェクトの全員が同じツールを利用可能
ユニバーサル
- パッケージマネージャー、ノードランタイム、OSに依存なく利用可能。

今まではnodebrewなどを利用することが、一般的でしたが、現在はVoltaを利用するケースが増えている印象です。

VoltaとNode.jsのインストール

voltaのインストールは以下のコマンドだけで完了です。

1

curl https://get.volta.sh | bash

パスが通っていないことがあるのでzshを利用している方は以下のコマンドでパスを通してください。

1
2
3


echo 'VOLTA_HOME=$HOME/.volta' >> ~/.zshrc
echo 'export PATH=$VOLTA_HOME/bin:$PATH' >> ~/.zshrc
source ~/.zshrc

動作を確認。バージョンが表示されれば問題なくインストールができています。

1

volta -v

voltaを利用してNode.jsをインストールします。
バージョンの指定をしない場合最新のLTSがインストールされます。

1

volta install node

yarnをインストールしてTypeScriptのプロジェクトを作成

npmとyarnの違い

npm, yarnともにNode.jsのパッケージマネージャーとなります。
それぞれの特徴は以下の通りです。

npm

Node.jsがリリースされた翌年（2010年）リリース
Node Package Managerの略
package-lock.jsonファイルを自動的に生成する
Node.jsをインストールすれば自動的にインストールされる

yarn

2016年リリース
Facebook、Google、Exponent、Tildeによって開発された新しいJavaScriptパッケージマネージャー
npｍと互換性がある
- 同じpackage.jsonが使える
npmより厳密にモジュールのバージョンを固定できる
npmよりインストールが速い

yarnの方が優れているように見えますが、最近ではnpmがアップデートされて機能の差はあまりないようです。
今回はyarnを利用してTypeScriptのプロジェクトを作成します。

yarnのインストール

voltaを利用してyarnをインストールします。

1

volta install yarn

インストールされているかを確認します。
listの結果にyarnが表示されれば問題なくインストールされています。

1

volta list

TypeScriptのプロジェクトを作成

yarnの初期化

1

yarn init -y

Node.jsのインストール

1

volta pin node@20.0.0

TypeScriptのインストール

1

yarn add typescript

node-tsのインストール

1

yarn add --dev ts-node

tsconfig.jsonを作成します。
tsconfig.jsonはTypeScriptの設定ファイルで、コンパイル時の設定を記述します。
今回は、console.logを利用するため、今回はtargetを es2016 に設定します。特にデフォルトで生成されるものから変更する必要はありません。

1

yarn tsc --init

サンプルプログラムを実行してみる。

1
2
3
4
5


echo "console.log('Hello, TypeScript!');" > hello.ts
yarn ts-node hello.ts

# 以下のように表示されれば成功
Hello, TypeScript!

無事にテストスクリプトが動きました。
以上でTypeScriptの開発環境のセットアップが完了です。

まとめ

本記事では、Voltaを利用してTypeScriptの開発環境を簡単にセットアップする方法について説明しました。 Voltaを利用することで、Node.jsのバージョン管理が簡単になり、開発環境のセットアップがスムーズに行えます。また、VoltaでNode.jsのバージョンを指定すると、package.jsonにバージョンが記述され、他の開発者とのバージョンの差異を解消することができる点も魅力的ですね。

TyeScriptにおけるEnumの使い方（TypeScript Enumの使い方）

ITIL v4 キャパシティ及びパフォーマンス管理について解説

Tue, 27 Feb 2024 08:53:36 +0900

概要

この記事では、ITIL v4のキャパシティ及びパフォーマンス管理について説明します。た、理解した内容をもとに自分の経験を当てはめキャパシティ及びパフォーマンス管理のプロセスについて説明します。

キャパシティおよびパフォーマンス管理とは

サービス及びサービスを支えるリソースのパフォーマンスを管理することです。
キャパシティとパフォーマンスの管理活動を通じて、サービスのパフォーマンスを最適化し、サービスのキャパシティを適切に確保することが目的です。

キャパシティ及びパフォーマンス管理のプロセス

キャパシティ及びパフォーマンス管理のプロセスは以下の2つがあります。

キャパシティとパフォーマンスコントロールの確立
サービスのキャパシティとパフォーマンスの分析と改善

キャパシティとパフォーマンスコントロールの確立

キャパシティとパフォーマンスコントロールの確立は、サービスが利用するITリソースの使用量と性能基準について、要件を利害関係者と合意し、それらを評価するタイミング・基準値・報告形式を決めることです。

以下の流れで実現されます。

サービスキャパシティとパフォーマンス要件の特定
サービスキャパシティとパフォーマンス要件の合意
キャパシティとパフォーマンスの要件の決定
キャパシティとパフォーマンス評価指標とレポートの設計

上記プロセスに対して筆者の経験を当てはめると以下の通りになりました。

サービスキャパシティとパフォーマンス要件の特定
- 筆者は社内PFとしてAPIを提供していたため、社内の利用者から求められるレイテンシー性能（99%ile Nms）を特定しました。
- 上記のしきい値をベースにパフォーマンス検証を行い、1インスタンスあたりのスループットを測定しました。
- スループットをベースに必要となる金額を算出しました。
サービスキャパシティとパフォーマンス要件の合意
- レイテンシー性能とスループットを関係者と合意を行いました。
キャパシティとパフォーマンスの要件の決定
- こちらについては合意内容と変わらず
キャパシティとパフォーマンス評価指標のレポートの設計
- パフォーマンスについてはDynatraceと呼ばれるトレーシングツールを利用して計測、レポートを作成しました。

サービスのキャパシティとパフォーマンスの分析と改善

サービスの出力ログ・インシデント情報から使用量と性能状況の問題点を分析する。

以下の流れで実現されます。

キャパシティとパフォーマンスの分析
キャパシティとパフォーマンスの報告
キャパシティとパフォーマンスの計画と設計

上記プロセスに対して筆者の経験を当てはめると以下の通りになりました。

キャパシティとパフォーマンスの分析
- パフォーマンスの分析については、Dynatraceを利用して、レイテンシー性能とスループットを分析しました。
- インシデント情報から、パフォーマンスの問題点を特定しました。
キャパシティとパフォーマンスの報告
- パフォーマンスの報告については、Dynatraceのダッシュボードを利用して、レイテンシー性能とスループットを可視化しました。
キャパシティとパフォーマンスの計画と設計
- 利用者の拡大によって現状のキャパシティでは受け入れが難しくなります。
- 需要予測を立て必要なキャパシティの増強計画を立てて、実行に移すようにしています。

まとめ

今回はキャパシティ及びパフォーマンス管理について学習した内容に基づき筆者の経験を当てはめ説明しました。キャパシティ及びパフォーマンス管理では、可用性管理相当のことをキャパシティとパフォーマンスの観点から行うことが理解できました。筆者の経験ではパフォーマンスの話と可用性の話についてはセットで行うことが多いのであまり独立して行わないと感じました。

ITIL v4 可用性管理について解説（関連ITIL v4記事）
ITIL v4 事業分析について解説（関連ITIL v4記事）

MacでStable Diffusion Web UIを使う方法

Mon, 12 Feb 2024 11:24:59 +0900

概要

この記事ではMacにStable Diffusion Web UIをインストールし、ローカルで利用する方法を紹介します。

Stable Diffusionとは

Stable Diffusionは、AIを用いた画像処理技術の一つです。テキストを入力することで、そのテキストに対応する画像を生成することができます。

以下は、Stable Diffusionのアニメ画像を出力できるモデルで、黒髪の少女を出力した例です。

Stable Diffusionを利用する方法

Stable Diffusionを利用方法は大きく以下の2種類に分かれます。

Hugging Face, Dream Studio などのwebアプリケーションを利用する
ローカルでStable Diffusion Web UIを利用する

本記事では、ローカルでStable Diffusion Web UIを利用する方法を紹介します。試しに使って見るだけであれば、webアプリケーションを利用するのが簡単ですが、画像を大量に生成する場合は制限があったり、費用がかかったりするので、ある程度の量を生成する場合はローカルで利用することをおすすめします。

Stable Diffusion Web UIをローカルで利用する方法

今回はAUTOMATIC1111氏が公開している、stable-diffusion-web-uiを利用します。

動作する環境を整える
stable-diffusion-web-uiをインストールする
モデルファイルを配置する
stable-diffusion-web-uiを起動し画像を生成する

1. 動作する環境を整える

まずは、ローカルで動作させるにあたって、Pythonやその他ライブラリが必要であるため、homebrewを利用してインストールします。

homebrewのインストール

1

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

homebrewのパスを通す

1

export PATH="$PATH:/opt/homebrew/bin/"

関連ライブラリのインストール

1

brew install cmake protobuf rust pyenv git wget

pyenvを用いて、Python環境のセットアップ。複数のPythonのバージョンを使い分けられるようにします。このあとにvenvも登場します。pythonの環境の構築についてはこちらの記事を参考にしてください。

1
2


pyenv install 3.10.6
pyenv local 3.10.6

2. stable-diffusion-web-uiをインストールする

git cloneでリポジトリをクローンします。

1
2


git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git
cd stable-diffusion-webui

venvで仮想環境を設定、他の環境を汚さないようにします。

1
2


python -m venv venv
source venv/bin/activate

これで環境構築は完了です。

3. モデルファイルを配置する

次にモデルファイルをダウンロードしてきて、stable-diffusion-webui/models/Stable-diffusion/ ディレクトリに配置します。
モデルファイルは以下のサイトからダウンロードできます。

今回はCivilaiから bule_pencil のモデルをダウンロードしてきて利用してみます。

Civilaiの検索窓にbule_pencilと入力し、検索します。
検索結果からbule_pencilを選択し、Downloadボタンをクリックします。

ダウンロードしたモデルをディレクトリに移します。

1

mv ~/Downloads/bluePencilXL_v401.safetensors models/Stable-diffusion/

4. stable-diffusion-web-uiを起動し画像を生成する

最後に、stable-diffusion-web-uiを起動し、画像を生成します。

1

./webui.sh

起動したらプロンプトにテキストを入力し、画像を生成します。

Stable Diffusion checkpointで先程ダウンロードしたbule_pencilを選択します。
promptに生成したい画像の要素を入力します
Negative promptに生成してほしくない画像の要素を入れます。
Generateをクリックします。

ピンク色のサングラスをかけた犬という意味のテキストを入力してみたところ、ちゃんと出力されました。
もちろん、他のテキストを入力することで、様々な画像を生成することができます。

まとめ

この記事ではMacにStable Diffusion Web UIをインストールし、ローカルで利用する方法を紹介しました。ローカルで利用することで、制限があったり、費用がかかったりするwebアプリケーションを利用するよりも、自由に画像を生成することができます。

ITIL v4 事業分析について解説

Fri, 09 Feb 2024 09:00:56 +0900

概要

ITIL v4の事業分析について、学習し理解した内容をまとめます。
また、理解した内容をもとに自分の経験を当てはめ、事業分析のプロセスについて説明します。

事業分析とは

事業分析とは、事業または他の何らかの要素を分析し、それらのニーズへの対応やビジネス上の課題を解決するためのソリューションを提案するプロセスです。
「事業」分析とされていますが、対象は事業だけでないことに注意が必要です。

事業分析手法の例

事業分析手法の例として以下のようなものがあります。

SWOT分析
ユーザーストーリー

具体的ない方法についてはここでは本題ではないため他のサイトに譲ります。
私は例には挙げられていませんが、カスタマージャーニーマップをよく使います。

事業分析のプロセス

事業分析のプロセスは以下の２つのプロセスがあります。

事業分析アプローチの設計と維持
事業分析とソリューションの特定

事業分析アプローチの設計と維持

このプロセスの焦点は、組織の現在および予想されるニーズに対処することにより、ビジネス分析に対する一貫した効果的なアプローチを確立することです。
以下の流れで実行されます。

組織と要件を分析する
ビジネス分析のアプローチ手法のレビュー
ビジネス分析アプローチを実行する

私が所属する組織ではあまり、事業レイヤーレベルの分析を行うことはないですが、一般的に要件・要求があればそれを特定の手法で分析しましょうというお話であると理解しています。

事業分析とソリューションの特定

このプロセスは、利害関係者のニーズと要件を分析することに重点が置かれています。分析の結果から利害関係者のニーズと要件に対処するためのソリューションの特定と提案が含まれています。
以下の流れで実行されます。

ステークホルダーからの情報収集と分析
ソリューションのオプションを定義し、推奨されるソリューションを特定する
ソリューション提供チームへのサポートの提供
ソリューションのパフォーマンスと評価

上記活動について、私の経験を当てはめると以下のように理解しました。

1,2について

ステークホルダーから情報を収集、得た情報の分析を行う。
分析結果から解決すべき課題(why)を特定、課題に対してどのような解決策があるか(what)を決定する。

3について

1,2で特定されたwhy, whatに対して、どのような解決策(how)があるかをプロダクトチームと一緒に考える
この際に解決手法とともに評価基準をきめ、どのような変化があればこのソリューションが成功したと言えるかを決定する。
- またこの際に効果はどの程度の時間軸で現れるのかの認識を合わせておくとよい。

4について

定めた評価基準に対して、ソリューションがどの程度達成されているかを定期的に評価する。
数値については手動集計だと見なくなるので、個人的には自動化してGrafanaなどで可視化することをおすすめします。

まとめ

今回は事業分析について学習した内容に基づき私の経験を当てはめ説明しました。
個人的な理解としては事業分析といいつつ事業だけを対象としないこと、分析といいつつ分析したあとのプロセスも含まれていることが理解できました。

参考

Business analysis management: ITIL 4 Practice Guide

ITIL v4 可用性管理について解説（関連ITIL v4記事）
ITIL v4 キャパシティ及びパフォーマンス管理について解説（関連ITIL v4記事）

VSCodeでGithub Copilotを使いこなす完全ガイド

Sun, 04 Feb 2024 22:34:51 +0900

概要

この記事では、VSCodeでGithub Copilotを設定して使う方法から、Markdownでの活用、Chat toolの使い方まで網羅的に説明します。前提としてGithub Copilotのアカウントが必要です。

VSCodeでGithub Copilotを使えるようにするまで

拡張機能をインストール

まずは、VSCodeに拡張機能をインストールします。 VSCode を開き、左メニューの四角形が4つあるアイコンをクリックし、検索用テキスト入力に「copilot」と入力します。「install」をクリックし、インストールを開始してください。

GitHubとの連携

installをクリックし、installが完了すれば以下のような画面が表示されるので、「Sign in to GitHub」をクリックします。

GitHubのアカウントへのアクセスを要求されるので「Allow」で許可します。

「Authorize Visual Studio Code」をクリックし、許可します。

これでGithub CopilotとVSCodeの連携が完了し、使えるようになりました。

使い方

基本的には、コードを書いていくだけで自動的に補完されるようになります。補完内容が提案されるので以下のショートカットを使いながらコードを書いていくと良いでしょう。

チートシート

機能	キー
提案を受け入れる	Tab
提案を拒否する	Esc
Copilotを開く	Ctrl + Enter
次の提案	Alt/Option + ]
前の提案	Alt/Option + [
インラインCopilotをトリガーする	Alt/Option + \

Markdownファイルでの補完を有効にする

Github Copilotは、デフォルトではMarkdownファイルでの補完が無効になっています。ブログ執筆などでMarkdownを使う場合は、有効化しておくと便利です。

設定方法

VSCodeでGitHub Copilotのプラグインのページを開きます
歯車アイコンをクリックし、設定を開きます
設定画面で markdown が false になっているので true に変更します

これでMarkdownファイルでもCopilotの補完が効くようになります。このブログもGithub Copilotで補完を行いながら書いており、かなり効率化できています。

Chat toolを使ってさらに便利に

Github Copilot Chatには「Chat tool」という機能があり、チャット内で様々なタスクを実行できます。

Chat toolの実行方法

基本的には #<command> <args> の形式でコマンドを入力します。

代表的なChat toolのコマンド

コマンド	機能
`#codebase`	現在のワークスペースを全部検索する
`#selection`	現在のエディタで選択しているコードをコンテキストとしてプロンプトに追加する
`#terminal_selection`	現在のターミナルで選択している部分をコンテキストとしてプロンプトに追加する。エラーが出たときにターミナルの出力を参照するのに便利です。
`#fetch_webpage`	URLを指定してwebページからコンテンツを取得してコンテキストとしてプロンプトに追加する

他にも便利なコマンドがあるので、公式ドキュメントを参照してください。

Github Copilot Chat tools

まとめ

VSCodeでGithub Copilotを設定して使う方法について説明しました。

基本設定: 拡張機能のインストールとGitHub連携
ショートカット: Tab/Escで提案の受け入れ・拒否
Markdown対応: 設定でmarkdownをtrueに変更
Chat tool: #codebaseや#selectionでコンテキストを追加

Github Copilotはソースコードだけではなく文章にも補完を行ってくれます。ぜひ活用してみてください。

ITIL v4 可用性管理について解説

Tue, 30 Jan 2024 20:34:58 +0900

概要

この記事では、ITIL v4の可用性管理について説明します。また、理解した内容をもとに自分の経験を当てはあめ、可用性管理のプロセスについて説明します。

可用性管理とは

可用性管理とは、サービスの可用性を確保するための活動のことです。可用性管理の目的は、サービスが顧客とユーザーのニーズを満たすために合意されたレベルの可用性を確実に提供することです。

可用性管理のプロセス

可用性管理のプロセスは以下２つがあります。

サービス可用性制御の確立
サービス可用性の分析と改善

サービス可用性制御の確立

サービス可用性制御の確立は、サービスの可用性を確保するための活動のことです。以下の流れで実現されます。

サービス可用性要件の特定
サービス可用性要件の合意
可用性測定要件の決定
可用性メトリクスと報告の設計

上記プロセスに対して自分の経験を当てはめると以下のように理解しました。

サービス可用性要件の特定
- どのような利用者がおり、サービスが停止したときの事業リスクなどの影響を特定する。
- 自分のサービスは社内のPFなので、各サービスがPFとして利用しておりそれぞれどのような影響があるかを特定しました。
サービス可用性要件の合意
- SLAの形でサービスの可用性（稼働率99%）などを合意する
- 稼働率では停止判定の基準や、例外事由なども明らかにしました。
可用性測定要件の決定
- 測定要件については可用性要件合意の段階で何をサービス停止とするかを決めているので、測定要件は特になし。
可用性メトリクスと報告の設計
- 基本的には「ダウンタイム/稼働時間」で設計
- 報告については、可用性メトリクスを可視化するためのダッシュボードを作成しました。

サービス可用性の分析と改善

サービス可用性の分析と改善は、その名の通り可用性の分析と改善を行うプロセスです。以下の流れで実現されます。

サービス可用性の分析
サービス可用性の報告
サービス可用性の計画と設計

上記プロセスに対して自分の経験を当てはめると以下のように理解しました。

サービス可用性の分析
- サービス可用性が達成されていることを確認し、集計します。
サービス可用性の報告
- 可用性をダッシュボードに反映、誰でも見られる状態にします。
サービス可用性の計画と設計
- 可用性を割るような障害が発生した場合、再発防止のための計画を立てました。

参考

Availability management: ITIL 4 Practice Guide

ITIL v4 事業分析について解説（関連ITIL v4記事）
ITIL v4 キャパシティ及びパフォーマンス管理について解説（関連ITIL v4記事）

S3のオブジェクトの存在確認をする方法【Python boto3】

Sat, 27 Jan 2024 21:41:37 +0900

概要

PythonでS3のオブジェクトが存在するかどうかを確認する方法を説明します。 boto3にはresourceとclientの2つのAPIがあり、それぞれの方法を紹介します。

実際にLINE Botの開発で、ユーザーごとの設定ファイルがS3に存在するかチェックする必要があり、この方法を使いました。

resource vs client どちらを使うべきか

boto3には2つのAPIレベルがあります。

API	特徴	適したユースケース
`resource`	高レベルAPI、オブジェクト指向	シンプルな操作、可読性重視
`client`	低レベルAPI、AWS APIに近い	細かい制御、パフォーマンス重視

結論: 単純な存在確認ならclientのhead_objectがおすすめです。理由は以下の通りです。

head_objectはオブジェクトのメタデータのみを取得するため軽量
resourceのload()も内部的にはhead_objectを呼んでいる
clientの方がAWS APIに近く、挙動が明確

boto3.clientを利用する方法（推奨）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


import boto3
from botocore.exceptions import ClientError

def check_s3_object_exists(bucket_name: str, object_key: str) -> bool:
 """S3オブジェクトの存在確認"""
 s3 = boto3.client('s3')
 try:
 s3.head_object(Bucket=bucket_name, Key=object_key)
 return True
 except ClientError as e:
 error_code = e.response['Error']['Code']
 if error_code == '404':
 return False
 # 404以外のエラー（権限不足など）は再raise
 raise

# 使用例
if check_s3_object_exists('my-bucket', 'path/to/file.json'):
 print("オブジェクトが存在します")
else:
 print("オブジェクトが存在しません")

ポイント

head_objectはオブジェクトの内容をダウンロードせず、メタデータのみを取得
404エラー以外（403: アクセス拒否など）は別のエラーなので再raiseする
関数化しておくとテストしやすい

boto3.resourceを利用する方法

オブジェクト指向的に書きたい場合はこちらも使えます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


import boto3
from botocore.exceptions import ClientError

def check_s3_object_exists_resource(bucket_name: str, object_key: str) -> bool:
 """S3オブジェクトの存在確認（resource版）"""
 s3 = boto3.resource('s3')
 try:
 s3.Object(bucket_name, object_key).load()
 return True
 except ClientError as e:
 error_code = e.response['Error']['Code']
 if error_code == '404':
 return False
 raise

よくあるハマりポイント

1. 権限不足を404と間違える

S3バケットへのアクセス権限がない場合、403エラーが返ります。 404だけをキャッチして「存在しない」と判断すると、権限の問題を見逃します。

1
2
3
4
5
6
7
8
9


# NG: 404以外のエラーを握りつぶしている
except ClientError:
 return False # 権限エラーも「存在しない」扱いになる

# OK: 404以外は再raise
except ClientError as e:
 if e.response['Error']['Code'] == '404':
 return False
 raise # 権限エラーなどは呼び出し元で処理

2. list_objectsを使う方法は非効率

list_objectsでプレフィックス検索する方法もありますが、オブジェクト数が多いと遅くなります。単一オブジェクトの存在確認にはhead_objectを使いましょう。

まとめ

S3オブジェクトの存在確認にはhead_objectを使う
404エラー以外は権限不足などの可能性があるので適切に処理する
resourceとclientどちらでも可能だが、clientの方がシンプル

参考

AWS Lambda + LINE Botで掃除リマインダーを作る
Pyenvとvenvを用いたローカル環境のセットアップ方法（Python環境構築）
MacでUVを用いてPythonの開発環境を構築する（モダンなPython環境構築）

AWS API GatewayとLambdaを連携させる方法

Sat, 13 Jan 2024 18:06:52 +0900

概要

AWS API GatewayとLambdaを連携させることで、API GatewayからLambdaを呼び出すことができます。本記事AWS API GatewayとLambdaを連携させる方法を紹介します。

前提条件

Lambda関数については作成されていることを前提としています。作成していない場合は、下記記事を参考に作成してください。

AWS Lambdaを作成する方法

どの形式でAPI GatewayとLambdaを連携させるかを考える

API GatewayとLambdaを連携させるに当たってどのような方式で連携させるか以下の2点について考える必要があります。

API Gatewayのリクエスト形式について
プロキシ統合が非プロキシ統合か

API Gatewayのリクエスト形式について

以下の形式から選択できます。

REST API
HTTP API
WebSocket API

この内、REST APIの形式で利用する場合は、REST APIかHTTP APIのどちらかを選択することになります。
REST APIの方が機能が多いですが、HTTP APIと比べコストがかかります。
特に複雑なことをしないのであればHTTP APIを選択するのが良いと思います。

詳細な比較内容については公式ドキュメントで公開されているのでそちらを参照してください。

プロキシ統合が非プロキシ統合か

プロキシ統合を利用することで、Lambdaから返される値のフォーマットが固定化されます。基本的にはプロキシ統合を利用することをおすすめします。

API Gateway で Lambda プロキシ統合を設定する

設定

Lambda関数を作成したら、トリガー追加を選択します。

API Gatewayを選択します。

トリガーを追加の画面で以下のように設定を行います。

設定がうまくいくと以下のような画面になります。

API endpoint に記載のエンドポイントにcurlなどでアクセスするとLambda関数が実行されます。

1
2
3


$ curl https://xxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/default/apigateway-get-sample

"Hello from Lambda!"%

まとめ

本記事ではAWS API GatewayとLambdaを連携させる方法を紹介しました。 API Gatewayと連携させることで外部から任意のタイミングでLambda関数を呼び出すことができるようになります。

プロダクト戦略の作り方

Mon, 08 Jan 2024 21:55:15 +0900

概要

良いプロダクト戦略の作り方について、「良い戦略、悪い戦略」という書籍をベースにまとめました。

背景

業務でプロダクトオーナーとして、前プロダクトオーナーからプロダクトを引き継ぎました。
引き継いだプロダクトにはプロダクト戦略がなく、プロダクトの方向性が定まっていない状態であったため、今後プロダクトをどうするかを含めて、プロダクト戦略を作成しました。

プロダクト戦略を作成するにあたって、そもそも「戦略」というものが人によって様々な意味に解釈されており、なんでも「戦略」という言葉を使ってしまう傾向があると常々感じていました。そこで、プロダクト戦略を作成するにあたって、どのような戦略を作成すれば良いのかを知るために、「良い戦略、悪い戦略」を読みました。

良い戦略とは

良い戦略とは、こちらの打つ手の効果が一気に高まるようなポイントを見つけ、そこに狙いを絞って手持ちのリソースを集中させることで、効果を最大化することができる戦略です。戦略とは組織が前に進むためにどのようにしたら良いかを示すものである必要があります。

良い戦略は、以下の3つの基本構造を持っています。

診断
基本方針
行動

診断

診断とは、状況を診断し取り組むべき課題を見極めることです。
良い診断は死活的に重要な問題点をより分け、複雑に絡み合った状況を明快に整理することができます。

戦略を立てる作業の多くは、今何が置きているのかを洗い出すことにあります。まずは情報を集めることが何よりも大切です。
本書ではコンサルが提案するようなフレームに割り当てるだけではまともな戦略はできない。とこき下ろしていますが情報をしっかりと集めた上でフレームに割り当て整理することを診断の段階で行うことは有意義だと私は考えています。

実際に私がプロダクト戦略を作成するにあたって、SWOT分析でプロダクトの置かれる状況を、インパクトマッピングを用いて現状の施策が一体誰にどのような影響を与えるのかの整理を行いました。
それぞれのやり方については、以下の記事や書籍を参照してください。

基本方針

基本方針とは、診断で見つかった課題にどう取り組むか、大きな方向性と総合的な方針を示すことです。
良い基本方針とは、目標でもビジョンではない、何曲に立ち向かう方法を固め、他の選択肢を排除することが基本方針である。と本書では述べられていました。
決定的な一点に努力を集中させることによって、大きな効果を上げることができます。

このため良い戦略の中には、その戦略に従うことによって何に対してリソースを割くのかがはっきりと分かるようになっていることが大切です。

私が戦略を立てた際には、インパクトマッピングで整理した内容をベースに、プロダクトの置かれた現状やビジョンをもとに勘案し、プロダクトの方向性を決めました。
リソースを選択する意味では、どのターゲットのセグメントに対して、どのような価値を提供するのかを明確にすることを意識しました。

行動

基本方針を実行するために設計された一貫性のある一連の行動のことです。戦略が存在することですべての行動をコーディネートして方針を実行することができます。

このため、良い戦略は、行動を実行するための指針が含まれていることが大切となります。

私が立てた戦略

上記をベースに私が立てた戦略は以下となりました。
会社で立てた戦略ですので、一部ぼかして書いています。

1

xx機能の利用者の新規利用コストを低減する

かなりシンプルなものになりましたが、以下のように良い戦略の3つの基本構造を満たしていると考えています。

診断
- プロダクトの状況、課題をベースに考えたときにxxの新規利用者を増やすことが会社の利益につながると考えました。
基本方針
- 新規利用者を確保するために導入コストを下げるという基本方針を定めました。
行動
- 基本方針を実現するためにいくつかのアプローチを用意し優先順位をつけました。
- ここについては行動を連想できるようなワードを戦略に含められればと考えましたが上記対応としました。

悪い戦略とは

最後に陥りがちな悪い戦略のパターンについて書いておきます。

悪い戦略の特徴

空疎である
- わかり切っていることを専門用語や業界用語で煙に巻くような内容
重大な問題に取り組まない
- 本来困難な課題を克服し、障害を乗り越えるためのものが戦略である。
- 達成容易性のみを考えた戦略は悪い戦略である。
目標と戦略と取り違えている
- 売りあげ10%向上など。それはただの目標である。
間違った戦略目標を掲げている
- 十分な周辺・原因の調査がなく戦略を掲げている状態。

まとめ

今回は、良いプロダクト戦略の作り方について、「良い戦略、悪い戦略」という書籍をベースにまとめました。一回でいきなり良い戦略は立てられないと考えています。ただ、戦略のない環境はただ闇雲に走っているだけなのでそれが成功したのか失敗したのかすら判断することができない最低の状態です。
最初は下手な戦略でも良いので、良い戦略とは何かを意識しつつ常に周りの状況を観察しながら、戦略をアップデートしプロダクトと組織の方向性を定めていくことが大切だと思います。

Twitter Social Cardの設定方法

Sat, 06 Jan 2024 21:45:12 +0900

概要

この記事では、Hugoで作ったブログにTwitter Social Cardを設定する方法を説明します。

Twitter Social Cardとは、Twitterで記事をシェアした際に表示される画像のことです。以下のような画像がTwitter Social Cardです。

Twitter Social Cardは、以下の種類があります。

Summary Card
Summary Card with Large Image
App Card
Player Card

この中でもブログのシェアを行う場合は、Summary Card か Summary Card with Large Image を利用することが多いです。

そのれぞれのカードがどのようなものかについてはTwitterの公式ドキュメントを参照してください。

Twitter Social Cardの設定方法は、以下の2つの方法があります。

テーマによる設定
テーマに依存しない設定

テーマによる設定

テーマによっては、Twitter Social Cardの設定を行うことができます。

今回は私が採用しているStackを例に説明します。

Stackでは、config.toml 対して以下のような設定を行うことでTwitter Social Cardの設定が可能です。

1
2
3
4
5
6
7
8


[opengraph.twitter]
site = ""
card = "summary" # summary or summary_large_image

[defaultImage.opengraph]
enabled = true
local = false
src = "/images/share.webp" # デフォルトで設定したいimageのパス

テーマに依存しない設定

テーマによっては、Twitter Social Cardの設定を行うことができません。自前で実装して、設定を行う必要があります。

Hugoの公式で実装のテンプレートが公開されていますので、それを利用することで容易に実装することが可能です。

うまくいかない場合

うまくいかない場合はうまく設定が反映されていない、megaタグが正しく設定されていない可能性があります。 Twitterから提供されているデバッグツールを利用して、設定が正しく反映されているか確認してみましょう。

まとめ

この記事では、Hugoで作ったブログにTwitter Social Cardを設定する方法を説明しました。 Social Cardを設定することで、Twitterで記事をシェアした際に、より多くの人に記事を読んでもらうことができますのでぜひ設定しましょう。

Hugo + Netlify + Githubでブログを公開する - ブログの初期構築
Google Search Consoleでブログを検索対象にする方法 - SEO対策

ChatGPTを利用してHugoで作ったブログを多言語対応する方法

Sun, 31 Dec 2023 20:46:36 +0900

概要

この記事では、ChatGPTを利用してHugoで作ったブログを多言語対応する方法を説明します。

GhatGPTを利用して記事を英語化する方法

Markdownで書かれた記事をChatGPTに英語化させます。英語化を実施するにあたって、なるべき体裁を崩さないようにするために、以下のようなプロンプトをChatGPTへ入力します。

1
2
3


マークダウンを体裁を崩さずに英語にしてください。
マークダウン以外の余分な出力は行わないでください。
英語化された内容をそのままコピーできる形で出力してください。

その後、日本語で書いた記事をそのまま貼り付けると、英語化されたMarkdownが出力されます。出力結果の左下のコピーボタンから出力結果をコピーすれば、英語化は完了です。

また、ChatGPTを利用する際はGPT3.5ではなく、課金をしてGPT4を利用することを強くおすすめします。 GPT4は月々お金がかかりますが、GPT3.5と比べて圧倒的に正しい回答を返す確率が高いので、英語化以外の用途にも使えます。

Hugoで多言語対応する方法

Hugoで多言語化を行うための設定方法を記載します。

設定ファイルの作成

config.tomlに以下のような設定を追加します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# デフォルトの言語を設定、設定しない場合英語がデフォルト判定されます。
defaultContentLanguage = "jp"

[languages]
 # 言語ごとに設定を変更します
 [languages.jp]
 title = "Bossagyu Blog"
 languageName = "ja-jp 🇯🇵"
 LanguageCode = "ja-jp"
 contentDir = "content" # 日本語ブログ記事を格納するディレクトリ
 [languages.jp.params]

 [languages.en]
 title = "Bossagyu Blog"
 languageName = "en-US 🇺🇸"
 LanguageCode = "en-US"
 contentDir = "content.en" # 英語ブログ記事を格納するディレクトリ
 [languages.en.params]

上記のような設定を行うことで、contentディレクトリに日本語の記事を、content.enディレクトリに英語の記事を書くことで多言語対応が可能となります。

最終的なディレクトリ構成は以下のような形になります。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


project/
├── content/
│ ├── index.md
│ └── blog/
│ ├── index.md
│ └── article1.md
└── content.en/
 ├── index.md
 └── blog/
 ├── index.md
 └── article1.en.md

また英語化したディレクトリの中には 記事名.en.md の拡張子とすることで、デフォルト言語に対する英語の記事として認識され、記事に言語変換用のアイコンが出力されるようになります。記事についてはGhatGPTを用いて英語化したものをコピー&ペーストするだけでOKです。

まとめ

この記事では、ChatGPTを利用してHugoで作ったブログを多言語対応する方法を説明しました。 ChatGPTを利用することで、英語化を簡単に行うことができます。また、多言語対応することで記事を日本以外の国にもリーチでき、より多くの人に記事を読んでもらえます。

ローコストで多言語対応できるのでぜひやってみましょう。

Hugo + Netlify + Githubでブログを公開する - ブログの初期構築

Lighthouseの使い方の紹介

Fri, 22 Dec 2023 23:08:00 +0900

概要

Lighthouseを用いて、ブログのパフォーマンスを計測する方法を解説します。

Lighthouseとは

LighthouseはGoogleが提供している、Webサイトのパフォーマンスを計測するツールです。 Google Chromeの拡張機能として提供されており、プラグインをインストールすることで利用することができます。

Lighthouseのインストール

Lighthouseをchromeウェブストアからインストールします。

分析したいサイトを開き、Lighthouseのアイコンをクリックします。

Generate reportをクリックすると、分析が始まります。
今回は私のブログのページで実行しました。

実行すると、以下のような結果が表示されます。
実行の完了までに約1分くらい時間がかかります。

結果の見方

Performance

ページの読み込み速度や画像の表示速度など、webサイトのパフォーマンスが評価される。 See calculatorのリンクをクリックすると詳細に飛べる。

Accessibility

すべてのユーザーがコンテンツにアクセス、サイト内を効率的に移動できるかどうかを確認する。スクロールすると、Accessibilityで指摘されている箇所が表示される。

コードスニペットを貼っているところの色のコントラストが弱いことと、リンクに説明がないことを指摘されています。

ただ、指摘されている内容は自分の記述ではなく、テンプレートに依存している部分なので、これを直そうと思うとHugoのテンプレートをオーバーライドする必要がありますね。。

Best Practices

ウェブページの健全性についてテストを行います。検証項目については結果から閲覧できます。

SEO

ページが検索エンジンの結果ランキング向けに最適化されているかを確認できます。

Progressive Web App

スマートフォン上のウェブページの読み込み速度を高速化できているか、PWAに最適化できているかを確認できます。今回はチェックしてません。

まとめ

Lighthouseを用いて、ブログのパフォーマンスを計測する方法を解説しました。特にSEOについては、Googleの検索結果に表示されるかどうかに影響するので、しっかりと対応しておきましょう。

Hugo + Netlify + Githubでブログを公開する - ブログの初期構築
HugoでGoogle Analyticsの設定をする方法 - アクセス解析

AWS EventBridgeを用いてLambdaを定期実行する方法

Thu, 21 Dec 2023 23:03:13 +0900

概要

AWS EventBridgeを用いてLambdaを定期実行する方法を解説します。

私はこの仕組みを使って、LINE Botに定期的にリマインド通知を送る機能を実装しました。たとえば「毎朝7時に掃除のリマインドを送る」といった処理を、サーバーを用意せずに実現できます。

AWS EventBridgeとは

AWS EventBridgeは、AWSのサービス間でイベントを受け渡すためのサービスです。主な用途は以下の2つです。

用途	説明
スケジュール実行	cron式やrate式で定期的にLambdaを実行
イベント駆動	S3へのファイルアップロードなどをトリガーにLambdaを実行

今回はスケジュール実行の方法を解説します。

実際のユースケース

EventBridge + Lambdaの定期実行は、以下のようなケースで役立ちます。

リマインド通知: 毎日決まった時間にSlackやLINEに通知
バッチ処理: 毎時データを集計してDBに保存
ヘルスチェック: 5分ごとに外部APIの死活監視
クリーンアップ: 毎日深夜に古いログを削除

私の場合は、掃除リマインダーBotで毎時ユーザーへの通知判定を行うために使っています。

前提

Lambda関数についてはすでに作成されていることを前提としています。 Lambda関数の作成方法については、AWS Lambda 開始方法を参照して作成してください。

手順

1. トリガーを追加

EventBridgeで実行する予定のLambda関数を選択し「トリガーを追加」を選択します。

2. EventBridgeを選択

トリガーから「EventBridge (CloudWatch Events)」を選択します。

3. スケジュールを設定

トリガーの選択を行うと、ルールの作成画面が表示されるので設定します。

4. 設定完了

設定が完了するとLambda関数のダイアグラムのトリガーにEventBridgeが追加されます。

cron式の書き方

EventBridgeのcron式は6つのフィールドで構成されます。

1

cron(分 時 日 月 曜日 年)

よく使うパターン

実行タイミング	cron式
毎日9時（UTC）	`cron(0 9 * * ? *)`
毎日9時（JST = UTC+9）	`cron(0 0 * * ? *)`
毎時0分	`cron(0 * * * ? *)`
5分ごと	`cron(0/5 * * * ? *)`
平日のみ毎朝9時（UTC）	`cron(0 9 ? * MON-FRI *)`
毎月1日の0時（UTC）	`cron(0 0 1 * ? *)`

注意: タイムゾーンはUTC

EventBridgeのcron式はUTC基準です。日本時間（JST）で設定したい場合は9時間引いてください。

例: 毎朝7時（JST）に実行 → cron(0 22 * * ? *) （前日の22時UTC）

実際に動かしてみた結果

私はLINEにメッセージを通知するFunctionを作って動かしてみました。 5分に1回通知がくるようになりました。

テストの際は短い間隔（5分など）で設定して動作確認し、本番では適切な間隔に変更するのがおすすめです。

コストについて

EventBridge + Lambdaの組み合わせは非常に低コストです。

サービス	無料枠	超過時の料金
EventBridge	無料	スケジュールルールは無料
Lambda	月100万リクエスト無料	$0.20/100万リクエスト

個人開発のリマインダーBot程度なら、ほぼ無料で運用できます。

ハマりポイント

1. タイムゾーンの罠

前述の通り、EventBridgeはUTC基準です。「毎朝9時」と設定したつもりが「夕方18時」に動いていた、というのはよくある失敗です。

2. 初回実行のタイミング

cron式を設定した直後は、次のスケジュールまで待つ必要があります。すぐにテストしたい場合は、Lambdaのテスト機能を使いましょう。

3. 削除を忘れずに

テスト用に作成したEventBridgeルールを放置すると、Lambdaが実行され続けます。不要になったルールは必ず削除しましょう。

まとめ

AWS EventBridgeを用いてLambdaを定期実行する方法を解説しました。

EventBridgeはスケジュール実行とイベント駆動の2つの用途がある
cron式はUTC基準なので、JSTで設定したい場合は9時間引く
個人開発レベルならほぼ無料で運用可能
不要になったルールは削除を忘れずに

サーバーレスで定期実行を実現できるので、リマインダーBotやバッチ処理などに活用してみてください。

Google Search Consoleを用いてブログをGoogle検索の対象にする方法

Mon, 18 Dec 2023 19:10:04 +0900

概要

Google検索で引っかかるようにするために、SEO対策を行いましょうとありますが、まずはGoogle検索に認識されないと話になりません。この記事では、Google Search Consoleを用いて自身が作成した独自ドメインのブログが、Google検索の対象となる方法を解説します。

実現までの流れ

Google Search Consoleの登録
ドメインの所有権の確認
サイトマップの登録
インデックス登録をリクエスト
まとめ

Google Search Consoleの登録

Google Search Consoleに登録します。

ドメインを選択肢、URLを入力します。

ドメインの所有権の確認

以下のような画像が表示されDNSの所有権を確認します。
(念のためTXTレコードの内容は黒く塗りつぶしています。)

ドメインのTXTにGoogleが指定した文字列を追加することで、所有権を確認することができます。ドメインのDNSの設定画面に移動し、TXTレコードを追加します。

私の場合はNetlifyでドメインを取得しているので、NetlifyのDNSの設定画面に移動します。 Domains -> Domain Settings -> DNS Records に移動し、TXTレコードを追加します。

レコードの内容はGoogle Search Consoleに表示されているものをコピーしてValueに貼り付けます。
(Valueの部分は黒く塗りつぶしています。)

DNSの反映を待ちます。ものによっては数時間かかる場合があります。

DNSの反映はコマンドラインからでも確認できます。

1

dig -t txt bossagyu.com

その後、Google Search Consoleの所有権の確認を押します。
これで所有権の確認が完了し、Google Search Consoleにドメインが登録されます。

サイトマップの登録

サイトマップを登録することで、Googleにサイトの構造を伝え、サイトのクロールを促進することができます。 Hugoで作成したブログの場合は、/sitemap.xmlにサイトマップが作成されているので、これを登録します。

Google Search Consoleの左側のメニューから「サイトマップ」を選択し、サイトマップを追加します。

インデックス登録をリクエスト

サイトマップに登録されていても、Googleがクロールして、その後インデックスが登録されるまでには時間がかかります。私の場合は数日待ってもインデックスが登録されなかったので、インデックス登録をリクエストしました。

Google Search Consoleの検索窓で登録したいURLを検索し、検索結果の右側にある「インデックス登録をリクエスト」を押します。

これでインデックス登録をリクエストできます。クリックしてから数時間でインデックスが登録されました。

まとめ

Google Search Consoleを用いて自身が作成した独自ドメインのブログが検索に引っかかるようにする方法を解説しました。
せっかくブログを作成したのに、Google検索に引っかからないのはもったいないので、ぜひ試してみてください。

Hugo + Netlify + Githubでブログを公開する - ブログの初期構築
HugoでGoogle Analyticsの設定をする方法 - アクセス解析
Lighthouseの使い方の紹介 - パフォーマンス計測

IntellijでAWS Toolkitを使ってLambdaを効率よく開発する

Tue, 12 Dec 2023 22:40:05 +0900

概要

IntellijでAWS Toolkitを使ってLambdaを効率よく開発する方法を解説します。

実現までの流れ

事前準備
AWS Toolkitのインストール
AWS Toolkitの設定
Lambdaの開発
Lambdaをローカルで実行
まとめ

事前準備

dockerのインストール

intellijで利用するAWS Toolkitでは、Lambda動作させるためにDockerを使用します。
このため事前にこちらを参考にDockerをインストールしておいてください。

AWS CLIのインストール

AWS CLI(SAM)をインストールします。
インストール方法はこちらを参考にしてください。

IntellijにSAM CLI executableのパスを File -> Settings -> Tools -> AWS Toolkit から設定します。
私の環境ではbrewでインストールしたので、以下のパスを設定しました。

AWS Toolkitのインストール

IntellijのプラグインからAWS Toolkitをインストールします。プラグインのインストールはこちらを参考にしてください。

AWS Toolkitの設定

AWS Toolkitを利用するためにはAWSの認証情報を設定する必要があります。

AWS ExplorerからAWSの認証情報を設定します。

Access Key IDとSecret Access KeyをAWSのコンソールから取得し、設定します。設定が完了したら、AWS ExplorerにAWSのリソースが表示されるようになります。

この画像ではリージョンが us-east-1 になっていますが、Lambdaを作成するリージョンに合わせてください。

Lambdaの開発

以下のようなコードスニペットを作成します。

lamda-sample.py

1
2
3


def lambda_handler(event, context):
 print("Hello World")
 return "Hello World!"

AWS ExplorerからLambdaを作成します。

Create Lambda Functionを選択し、必要な値を入力します。
Handlerにはコードスニペットの <ファイル名>.<関数名> を入力してください。

これでLambdaの作成が完了しました。

Lambdaをローカルで実行

またToolkitを利用すると、Lambdaをローカルで実行することができます。

Runを選択すると、Lambdaがローカルで実行されます。

まとめ

IntellijでAWS Toolkitを使ってLambdaを効率よく開発する方法を解説しました。 Intellijで開発してローカルで実行できるので、開発効率がかなり上がります。

IntellijでのGithub Copilotの使い方

Mon, 11 Dec 2023 22:45:40 +0900

概要

Github CopilotをIntellijで使う方法を解説します。合わせてショートカットのチートシートを記載します。

実現までの流れ

Github Copilotの登録
Intellijの設定
Github Copilotの利用
まとめ

Github Copilotの登録

Github Copilot のリンクからGithub Copilotに登録します。

Intellijの設定

IntellijのプラグインからGithub Copilotをインストールします。

インストールが完了したら、Intellijを再起動します。

Github Copilotの利用

ショートカット一覧

Intellijでコードを書いていると、Github Copilotがコードを補完してくれます。

macのショートカットの一覧は以下のとおりです。

ショートカット	機能
`tab`	コードを補完する
`Option` + `]`	次の補完候補を表示する
`Option` + `[`	前の補完候補を表示する
`Command` + `→`	提案の次の単語のみ受け入れる

コメントによるコード補完

Github Copilotはコメントによるコード補完も行うことができます。

例えば、以下のようなコメントを書くと、コメントの内容に応じてコードを補完してくれます。

1
2
3
4


// このメソッドは、引数の値を2倍にして返す ← 書いたコメント
public int double(int value) { // ← 生成されたコード
 return value * 2;
}

まとめ

IntellijでGithub Copilotを利用する方法を解説しました。この記事はGithub Copilotを利用して書いており、Markdownでのブログ作成でもかなり補完してくれるので、気になる人は試してみてください。

Pyenvとvenvを用いたローカル環境のセットアップ方法

Sun, 10 Dec 2023 23:19:33 +0900

概要

macのローカル環境で開発を行う際のpythonの環境構築の方法について記載します。
今回は以下の２つの仕組みを利用して、pythonのバージョン管理と仮想環境の管理を行います。

pyenv
- 複数のpythonのバージョンを扱うために利用します。
venv
- プロジェクトごとに環境を分けるために利用します。

それぞれの違いや必要性の解説はこちらの記事が参考になります。

Pythonのインストール

まずは、ローカル環境にPyenvをインストールし、任意のPythonバージョンを利用できるようにします。

pyenvをインストールします。

1

brew install pyenv

インストールしたpyenvのバージョンを確認します。

1
2


pyenv --version
pyenv 2.3.35

zshに設定を追加します。

1
2
3


echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.zshrc
echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.zshrc
echo -e 'if command -v pyenv 1>/dev/null 2>&1; then\n eval "$(pyenv init -)"\nfi' >> ~/.zshrc

.zshrcの内容を読み込みます。

1

source ~/.zshrc

インストール可能なPythonのバージョン一覧を表示します。

1

pyenv install --list

指定したバージョンをインストールします。

1

pyenv install 3.11.7

プロジェクトフォルダに指定したPythonのバージョンを利用します。

1
2
3


cd <作成したプロジェクトフォルダ>
pyenv local 3.11.7
pyenv versions

globalの場合は全体に反映されます。

1

pyenv global 3.11.7

実行されているpythonのバージョンを確認します。

1

python -V

venvで仮想環境の作成

プロジェクトのディレクトリに仮想環境を作成します。

1
2


# python -m venv <仮想環境名>
python -m venv venv

仮想環境を有効化します。

1

source venv/bin/activate

ディアクティベートは以下のコマンドで実行できます。

1

deactivate

venvのアップデート方法

依存パッケージを最新化する場合は、仮想環境を有効化した上で以下を実行します。requirements.txt を利用しているなら、ファイルを更新した後に再インストールするとよいでしょう。

1
2
3


source venv/bin/activate
pip install --upgrade pip
pip install -U -r requirements.txt

Pythonのマイナーバージョンを上げるときは、pyenv で新しいバージョンを入れ直したあと、仮想環境を作り直すとライブラリの整合性が保ちやすいです。

1
2
3
4
5
6


pyenv install 3.12.2
pyenv local 3.12.2
rm -rf venv
python -m venv venv
source venv/bin/activate
pip install -U -r requirements.txt

venvの削除方法

不要になった仮想環境はディレクトリごと削除すればよいです。作業ディレクトリを確認した上で実行してください。

1

rm -rf venv

以上でローカル環境の構築が完了です。

MacでUVを用いてPythonの開発環境を構築する（モダンな代替ツールとして）

HugoでGoogle Analyticsの設定をする方法

Sat, 09 Dec 2023 18:09:42 +0900

概要

HugoをでGoogle Analyticsを設定する方法をサクッと解説します。

実現までの流れ

Google Analyticsへの登録
トラッキングIDの取得
Hugoの設定にトラッキングIDを追加

Google Analyticsの登録

[GA4] アナリティクスで新しいウェブサイトまたはアプリのセットアップを行うに従い登録を行います。
データストリームを追加すると、トラッキングIDが取得できるのでメモしておきます。 ※ トラッキングIDは日本語訳の影響か、測定IDという表示になっています。

Hugoの設定にトラッキングIDを追加

tomlに設定を追加

config.tomlにgoogleAnalytics = トラッキングIDを追加します。

1
2
3
4
5
6


baseURL = 'https://bossagyu.com'
languageCode = 'ja-jp'
title = 'Bossagyu Blog'
theme = 'hugo-bearcub'
googleAnalytics = "G-1234ABCDEF"
# ↑ この行を追加、トラッキングIDは自分のものに変更してください。

トラッキングコードを埋め込む

テンプレートによってはtomlの設定を入れるだけで読めるものもあるみたいですが、私の使用しているbearcubのテンプレートは対応してなかったので、自分でヘッダにトラッキングコードを読み込むように追加します。

コードスニペットについてはまくまく Hugo ノートを参考にさせていただきました。

トラッキングコードを読むために layouts/partials/analytics.html を作成する。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


{{ if not .Site.IsServer }}
{{ with .Site.GoogleAnalytics }}
<!-- Google tag (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id={{ . }}"></script>
<script>
 window.dataLayer = window.dataLayer || [];
 function gtag(){dataLayer.push(arguments);}
 gtag('js', new Date());

 gtag('config', '{{ . }}');
</script>
{{ end }}
{{ end }}

ページヘッダで analytics.html を読み込むようにする。

1
2
3


# テンプレートの内容をコピーしてきてオーバーライドする
cp themes/hugo-bearcub/layouts/_default/baseof.html layouts/_default/baseof.html
vim layouts/_default/baseof.html

baseof.htmlに{{- partial "analytics" . -}} を追加する。

1
2
3
4
5
6


<!DOCTYPE html>
<html lang="{{ with .Site.LanguageCode }}{{ . }}{{ else }}en-US{{ end }}">

<head>
 {{- partial "analytics" . -}}
 <meta http-equiv="X-Clacks-Overhead" content="GNU Terry Pratchett" /

上記ソースコードを追加した状態で、再度ビルドするとGoogle Analyticsにデータが送信されるようになります。

tips

こちらの対応をしても、Google Analyticsにデータが連携されていないように見える場合は、タグの追加がうまくいっていない可能性があります。
まずはタグがちゃんと入っているかの切り分けをするために、googleデベロッパーツールを開きトラッキングがhtml内に含まれているか確認してみるとよいです。

Hugo + Netlify + Githubでブログを公開する - ブログの初期構築
Google Search Consoleでブログを検索対象にする方法 - SEO対策

LINE Messaging APIの登録と使い方

Thu, 07 Dec 2023 09:37:00 +0900

概要

LINEのBotを利用してアプリケーションを作ってみようと考えたのでまずはBotを利用できる状態にする。
本ページでは一番最初にLINE Message APIの登録の方法とcurlでコマンドラインからメッセージを送る方法を紹介します。

Messaging APIを利用する

LINE Developers にログインしてプロバイダーを作成する。

プロバイダーとは(説明)

1
2


LINE Developersサイトでは、サービスを提供し、ユーザーの情報を取得する開発者個人、
企業、または団体等をサービス提供者（LINEミニアプリではサービス事業主）と呼びます。

なので好きな文字列を入れる。

そのまま新規チャンネルを作成する。

このまま作成ボタンを押すと新規チャンネルが作成される

コマンドラインからポストをする

Messaging API設定からQRコードを読みこんで友達追加する。

Messaging API設定から「チャンネルアクセストークン(長期)」を取得チャンネル基本設定から「あなたのユーザーID」取得

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


TOKEN="<チャンネルアクセストークン(長期)>"
ID="<あなたのユーザーID>"
UUID=$(uuidgen | tr "[:upper:]" "[:lower:]")

curl -v -X POST https://api.line.me/v2/bot/message/push \
-H 'Content-Type: application/json' \
-H "Authorization: Bearer ${TOKEN}" \
-H "X-Line-Retry-Key: " \
-d "{
 \"to\": \"${ID}\",
 \"messages\":[
 {
 \"type\":\"text\",
 \"text\":\"Hello, world1\"
 }
 ]
}"

レスポンスが帰ってきて、LINEのトーク画面でBotからの投稿が行われていれば成功！

掃除を忘れない！掃除リマインダーLINE Bot（LINE Botの実践プロジェクト）

Hugo + Netlify + Githubでブログを公開する

Sat, 02 Dec 2023 00:59:37 +0900

概要

Hugoで作ったサイトをGithubで管理、Netlifyでビルドした手順を0から作れるよう記載します。この方式にすると手元でMarkDownで書いたブログをGithubにPushするだけで簡単に公開できるようになります。

Faviconの設定方法も合わせて解説します。

流れ

Hugoでサイトを生成
Githubにプッシュ
Netlifyでデプロイ
Faviconを設定

Hugoで静的サイトを生成

まずはHugoをインストールします。

1

brew install hugo

blogの雛形を作成します。

1

hugo new site my-blog

ブログに適応するテーマをsubmoduleとして追加します。

1
2
3
4
5


cd my-blog
git init

# テーマをgithubのsubmoduleとして追加
git submodule add https://github.com/theNewDynamic/gohugo-theme-ananke.git themes/ananke

hugo.tomlに記載することでテーマを適応する。

1

echo "theme = 'ananke'" >> config.toml

サーバを起動させます。

1

hugo server

起動ログの Web Server is available at http://localhost:51517/ (bind address 127.0.0.1) のような記述の http://localhost:51517/ にアクセスすればローカルに起動した静的サイトが閲覧できます。

Tips

Hugoのテーマを変えたい場合は、Hugo Themas から好きなものを選んで変えてください。
- これは後からでも変えられるのでとりあえずNetlifyでビルドするところまで走り切るのがおすすめ。
Tomlファイルの書き方は Configure Hugo に記載されています。

Githubにpush

Github にリポジトリを作成。
作成後以下のコマンドを実行し、サイトをpushします。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


cd my-blog
echo .hugo_build.lock >> .gitignore
git add .
git commit -m "first commit"
git branch -M main

# <user name>は自分のユーザー名に置き換えてください。
# 今回はmy-blogというリポジトリを作成している例です。
git remote add origin git@github.com:<user name>/my-blog
git push -u origin main

pushが完了するとGithubのUI上でソースコードが閲覧できる状態になっています。

Netlifyでデプロイ

netlify へアクセスし、デプロイを行う。
Hugoの公式で案内があるのでこちらを参考に連携を行う。

指示に従いデプロイを完了すると以下のようにDeployの結果が published になる。

サイト上に表示されたURLをクリックするとデプロイされたサイトにアクセスできる。

これでデプロイまではおしまい。以降は変更を加えてmainにpushするだけで自動デプロイが走り、サイトの内容が更新されるようになる。

Faviconを設定する

Faviconとは、ウェブサイトのブックマークやタブ、ホーム画面などに表示されるアイコンのことです。 Googleより検索結果に表示されるためのfaviconのガイドラインが公開されており、こちらに従うことで検索結果にも表示されるようになります。

Faviconの作成

Faviconを作成するには、以下のサイトを利用します。

Favicon.ico & App Icon Generator

サイトにアクセスし、faviconにしたい画像をアップロードして「Generate Favicon」をクリックします。その後表示される画面で、「Download the generated favicon」のリンクをクリックすると、faviconがダウンロードできます。

HugoでFaviconを表示する

HugoでFaviconを表示するには、themeによっても違いますが、多くのテーマでは以下のようにtomlに設定するだけでfaviconが表示できます。

1
2


[params]
 favicon = "images/favicon.ico"

ダウンロードしたfavicon.icoをstatic/images/ディレクトリに配置して、上記の設定を追加してください。

まとめ

Hugo + Netlify + Githubでブログを公開する方法を解説しました。

Hugo: 静的サイトを生成
Github: ソースコードを管理
Netlify: 自動デプロイ
Favicon: ブランディングのための設定

この構成なら、Markdownで記事を書いてGithubにpushするだけで自動的にサイトが更新されます。

HugoでGoogle Analyticsの設定をする方法 - アクセス解析の導入
Google Search Consoleでブログを検索対象にする方法 - SEO対策
Lighthouseの使い方の紹介 - パフォーマンス計測
ChatGPTを利用してHugoで作ったブログを多言語対応する方法 - 多言語対応
Twitter Social Cardの設定方法 - SNS共有の最適化

Blog on Bossagyu Blog

技術習熟の3つのモデル：ドレイファス・守破離・意識的能力の4段階

概要

なぜ習熟段階を理解するのか

ドレイファスモデル

出自と背景

5段階の構造

段階を移るときに起きる認知の変化

守破離

出自と背景

3段階の構造

西洋モデルとの違い

現代での応用例

意識的能力の4段階

出自と背景

4段階の構造

心理面の意義と第5段階

3つのフレームワークの比較

共通点

相違点

どのモデルをいつ使うか

応用：学習とプロダクト設計への活かし方

1. 自分の学習計画に使う

2. 他者の指導・メンタリングに使う

3. プロダクト・アプリ設計に使う

まとめ

参考文献

FastAPIでCRUD APIを作る入門チュートリアル

概要

前提条件

環境構築

Hello World

Swagger UIの確認

CRUD APIの実装

モデルの定義

作成（POST）

一覧取得（GET）

個別取得（GET）

更新（PUT）

削除（DELETE）

完成したコード

動作確認

1. TODOの作成

2. 一覧取得

3. 更新

4. 削除

まとめ

関連記事

GCSとGemini File Search APIを自動同期するイベント駆動バックエンドの設計

概要

システム全体像

各コンポーネントの役割

イベント駆動アーキテクチャの設計

なぜイベント駆動を選んだか

Eventarcによるイベントルーティング

ファイルアップロード時の処理フロー

ファイル削除時の処理フロー

Gemini File Search APIとの統合

GCPエコシステムでの統一

File Search Storeの概要

メタデータを活用した管理

汎用性を持たせた設計の工夫

パスベースのメタデータ抽出

GCSとGemini File Search APIの状態同期の保証

ローカルダウンロード経由の設計

エラーハンドリングと運用設計

常に200 OKを返す設計

Slack通知によるエラー監視

遅延初期化によるクライアント管理

まとめ

関連記事

【初心者向け】掃除リマインダーBotの使い方チュートリアル

このチュートリアルで学べること

Step 1: 友だち追加

Step 2: タスクを追加する

ポイント

Step 3: 通知を設定する

ポイント

Step 4: 通知を受け取る

Step 5: タスクを完了する