OmniAICreator/Qiita-1.07M huggingface dataset:
【紙運用の会社向け】紙をスキャンして綺麗に文字起こししてデジタル化しよう！Tesseract OCRで画像から日本語文字を抽出するまでの手順

## 🧠 はじめに

こんにちは、大企業・中小企業・SE・営業・経営を経験し、現在は製造業を中心にデジタル化、DX支援などをしておりますせいやです。

最近、AI の進化が凄く、画像認識のレベルも上がりました。
一方で、日本の企業の半分以上は「紙運用」のままの企業が多く、AIの恩恵を受けにくいです。

そんな貴方に、紙運用でもAIを使えるようにするのが、今日のテーマです。

「紙をスキャンして、文字起こしして、分類して、csv やスプレッドシートに保存する方法ないかなぁ？」と思っている方

この投稿を読めば、実現できます！

---

## 🎯 この記事でできること

- `.tif` 形式のスキャン画像から日本語テキストを自動で読み取る
- Windows + VSCode 環境で Python + Tesseract OCR を動かす
- よくあるエラー（Unicode escape）も丁寧に解決
- ChatGPT APIとの連携に進む準備として最適

---

## 🛠 環境構築ステップ

### ✅ 1. Pythonをインストール

[公式サイト](https://www.python.org/downloads/windows/) から最新版をインストール  
インストール時に「Add Python to PATH」にチェックを忘れずに！

---

### ✅ 2. VSCodeで作業用フォルダを作成

```plaintext
C:\Users\User\Documents\Python\scanAutomate\
````

上記をプロジェクトフォルダとして、ここに `.py` ファイルを置いて作業します。

---

### ✅ 3. 必要なPythonライブラリをインストール

ターミナルで以下を実行：

```bash
pip install pytesseract pillow
```

---

### ✅ 4. Tesseract OCRをインストール（日本語対応）

#### ① 公式からインストーラーをダウンロード

👉 [https://github.com/tesseract-ocr/tesseract](https://github.com/tesseract-ocr/tesseract)

#### ② インストール後のパス（例）を確認：

```plaintext
C:\Program Files\Tesseract-OCR\
```

#### ③ 環境変数にこのパスを追加する

* Windows検索で「環境変数」→「Path」編集→上記のパスを追加
* 追加後、ターミナルで以下を実行して確認：

```bash
tesseract --version
```

出力例：

```
tesseract v5.4.0.20240606
```

---

## ✅ 5. OCR実行用スクリプト（tif画像対応）

### 📄 ファイル名例：`ocr_test.py`

```python
from PIL import Image
import pytesseract

# TIF画像ファイルのパス（スラッシュ or r"" でエスケープ）
img_path = r"C:/Users/User/Documents/Python/scanAutomate/xxxx.tif"

# OCR処理（日本語）
text = pytesseract.image_to_string(Image.open(img_path), lang='jpn')

print("----- 読み取ったテキスト -----")
print(text)
print("----------------------------")
```

### ✅ 補足：パス指定の注意点

以下のようなエラーが出たら、`\` が原因です：

```plaintext
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position...
```

🔧 解決方法：

* `\\` を使う
* または先頭に `r` をつけて： `r"C:\..."` にする
* または `/` にする（WindowsでもOK）

---

## ✅ 6. 実行方法

```bash
python ocr_test.py
```

画像内の日本語テキストがターミナルに表示されれば成功です！

---

## 🎉 出力例

```plaintext
----- 読み取ったテキスト -----
株式会社サンプル
注文番号：12345
納期：2025年6月30日
...
----------------------------
```

---

## 🧠 この先の展望

このOCR結果を元に、以下のような活用が可能です：

* ChatGPT APIに連携して **分類・金額・日付の抽出**
* OCR結果を **Excel/CSVに自動保存**
* スキャンフォルダを監視して **完全自動処理**

---

## ✅ まとめ

| ステップ                          | 内容           |
| ----------------------------- | ------------ |
| Python + Pillow + pytesseract | OCR実行環境の構築   |
| Tesseract + 日本語学習データ          | 日本語OCRを可能に   |
| ファイルパスの工夫                     | よくあるエラーを回避   |
| tif画像 → OCR → print出力         | 最小構成の動作確認完了！ |

---

## 📩 最後に

実務やDX現場で使いたい方の参考になれば幸いです！

```
M4 MacBook Proにインストールしたアプリ

# はじめに
<!-- 発端や概要を記載 -->
M4 MacBook Proを購入し、アプリをインストールし直しました。
いくつかメモを残します。

# 目次
<!-- タイトルとアンカー名を編集 -->
1. [基本機能](#基本機能)
1. [お絵描き](#お絵描き)
1. [コーディング](#コーディング)
1. [ドキュメント関連](#ドキュメント関連)
1. [最後に](#最後に)
1. [参考文献](#参考文献)

<!-- 各チャプター -->
<a id="#基本機"></a>
# 基本機能
  
- [Chrome](https://www.google.com/intl/ja_jp/chrome/)
  - ブラウザはChrome派なんです

- [DisplayLink](https://www.synaptics.com/products/displaylink-graphics/downloads/macos)
  - DisplayLinkで周辺環境を構築しているので必須

- [Logi Options+](https://support.logi.com/hc/ja/articles/23439533588247-Download-ERGO-M575SP-JP)
  - トラックボールの設定変更用です
  - ポイントの速度やジェスチャーコントロールなどを使うためにインストールします

- [HHKB](https://happyhackingkb.com/jp/download/)
  - HHKB Professional HYBRIDを使っているのでツールが必要なDLします
  - 私は不要なのでbluetoothの接続だけしました
  - Fn+Qでペアリング待機→Fn+Control+(1-4の数字)で割り当て→システム設定のキーボードから接続

- [IJ Scan Utility Lite Ver.4.1.2](https://canon.jp/support/software/os/select?pr=4811&os=167)
  - プリンターのオンライン印刷ソフトをインストールします


<a id="#お絵描き"></a>
# お絵描き

- [wacom](https://tablet.wacom.co.jp/download/down1.html?_gl=1*8513d1*_ga*MTA1OTk3NzE2MC4xNzQzNDM2MzMw*_ga_5XHN22BY8E*MTc0MzQzNjMyOS4xLjEuMTc0MzQzNjU0NC41Ny4wLjE0OTkxODg0OTI.)
  - 液晶タブレット(wacom one 13)を使っているのでこちらで製品を選んでドライバーをインストール

- [CLIP STUDIO](https://www.clipstudio.net/ja/dl/latest/)
  - CLIP STUDIOの1デバイスプランで契約しているので、インストール後に前のMacを認証解除する必要があります

 
<a id="#コーディング"></a>
# コーディング

- [Visual Studio Code](https://code.visualstudio.com/)
  - みんな大好きなエディタ

- [Homebrew](https://brew.sh/)
  - お馴染みのパッケージ管理ツール

- git
    - Homebrewをインストールした後に下記
        ```
        $ brew install git
        ```
    - install後の設定は[こちら](https://qiita.com/genmai99/items/ff700738bb87dfbbba14)を参照

<a id="#ドキュメント関連"></a>
# ドキュメント関連

- [Obsidian](https://obsidian.md/)
  - iCloud+でiPhoneと連携してノートを整理してます。べんり

<a id="#最後に"></a>
# 最後に

その他、追加したらまた編集しようかと思います。


<a id="#参考文献"></a>
# 参考文献
“地味バグ”の発見から学んだ“根本原因の探し方”

Unity個人開発やアプリ製作で、\*\*目立たないけどジワジワと問題を引き起こす“地味バグ”\*\*に悩まされることはありませんか？
本記事では、筆者が実際に遭遇した“地味バグ”を例に、**どうやって根本原因を特定し、対処につなげたか**を整理しています。

---

## 1. なぜ“地味バグ”は怖いのか？

漂点なエラーは即対応できても、“地味バグ”は…

* 再現できない／時々しか起きない
* 起きてるか不明矩で気のせいになりやすい
* 気づかずリリースされると大問題に

**記録・検証・仮説の積み重ねが、品質を支える鍵です。**

---

## 2. 根本原因の探し方

実例に潤って、発生から解決までのプロセスを紹介します。

### (1) 再現条件を徹底的に流出す

* 「どの操作・どの画面・○○で発生する？」をメモ
* 一回でも発生したタイミングは絶対記録
* 絶対起きるものとランダムなものを振り分けることが重要

---

### (2) 変更点・イレギュラー操作に注目

* 最近のコード変更や設定もれを流出
* 普段しない操作（裏技操作）を試してみる
* バージョン違いで症状に差が出ないか確認

---

### (3) ログとエラーを徹底収集

* Warning・Error・Debug.Logを見逃さない
* ログに時刻・関数名・変数など細かく記録
* 詳細ログを一時適用して挙動を可視化

---

### (4) 同様事象の情報を探す

* Qiita／Zenn／StackOverflow／公式フォーラムで類似ケースを検索
* Unityバージョン依存や他プロジェクトで発生例がないかチェック

---

### (5) 仮説 → 確認 → 結論を繰り返す

* 原因候補リストを作成し、順番に検証
* 変更時には必ずビフォー・アフターで挙動記録
* 特定後は「直解になっていた理由」を振り返る

---

## 3. 次に活かす工夫

* 発生バグとその解決策を必ずドキュメント化
* 「他でも起きないか？」を意識してコード見直し
* デバッグログやテストケースはテンプレ化して使い回し
* 解決の過程をアウトプットし、自分と他人の学びに役立てる

---

## まとめ

“地味バグ”ほど難解ですが、根本原因にたどり着いた時の学びは大きいです。
**記録・検証・仮説思考を習慣化することで、バグを味方に変えられます。**

---

### 最後に…

## ブログでもUnityや個人開発ネタを発信中です！

開発ノウハウやアプリ製作過程、Unity連携系のハマりポイントなど
より深採りした内容をブログにまとめています。
▶ [https://syunpp.com](https://syunpp.com)

## 公開中のアプリ一覧はこちら！

実際にUnityで開発してリリース済みのアプリ一覧をまとめています。
▶ [https://syunpp.com/公開中のアプリ一覧/](https://syunpp.com/公開中のアプリ一覧/)

## YouTubeショートでもゲーム開発の裏側を公開中！

Unityで製作中のゲームの進捗や演出テスト、実装の様子を
ショート動画でタイムラプス形式にまとめて発信しています。
▶ [https://www.youtube.com/@syunpp\_8413/shorts](https://www.youtube.com/@syunpp_8413/shorts)
Power Automate　思いつかない問題

# 話の背景
Power Automateに「複数の項目の取得」というアクションがあります。
目的はSharePoint Onlineのリストの検索です。
フィルタークエリと呼ばれる条件文を書く時の話です。
例えば、item01 eq 'AAAA' AND item02 ne 'BBBB'  
（item01はAAAAである、且つ、item02はBBBBではない場合。）

# 問題
PowerAutomate のユーザ画面で、マウスがクエリのところにかざすと、条件１ AND 条件２みたいなプロンプトが表示されました。上記の通り記載すると、いつまで経っても実行が通りません。

# 解決
試しに、ANDを小文字にしたところ、通った！
正しい書き方は、 item01 eq 'value1' and item02 ne 'value2'
andは小文字でないとならないようです。

製品プロンプトと実際の結果が異なります。


Power Automateはほかにも、いくつか妙なところがあります。
ローコードと言われているが、普通のプログラミングよりも細心な注意が必要と思われます。
あくまで個人意見です。ご参考まで。
一般ユーザーの権限だけでSalesforceレポートで選択肢の割合を表示する

# 割合を計算するだけで項目を作るのはどうなのか？

日本でSalesforceブログを書いている人の多くは、導入支援企業に属しているように思います。  
そのためか、Salesforce導入支援の現場では「集計に使いたいから項目を追加で作ろう」という判断を、わりと容易に行いがちです。

しかし、実際に運用が始まったあとに**新たな項目を作る**というのは、組織運用上かなりハードルが高いです。  
（※逆に「すぐ作れちゃう環境」だとすれば、それはそれで問題です）

新しい項目を作るということは、プロファイル設定やレイアウト調整、監査対応など、副作用が多く発生します。軽く見積もらない方がいいです。

## 本記事の目的

今回は、「割合を出したい」という目的に対して、**オブジェクトに新しい項目を追加せずに**対応する方法について整理して紹介します。

---

## 項目を作らずに割合を出す方法

1. **円グラフや100%積上グラフで割合を示す**
   - 最もシンプル。グラフで割合を表現し、マウスオーバーで数値も確認できる
   - グルーピングしてグラフを表示するだけで済む

2. **バケット項目を使って、選択リストを欲しい粒度にしてグラフにする**
   - 1の応用。「バケット項目」を使えば、分類を変えるだけで集計粒度を変えられる
   - 選択肢リストを選ぶだけなので一般ユーザーにとっても理解しやすい

3. **集計関数（例: PARENTGROUPVALなど）を使って割合を出す**
   - レポート内で数値を持ちたい場合は、集計数式を使うことになる
   - ロジックを理解すれば、他の集計にも応用できる

4. **行レベル数式で選択肢をフラグ化し、割合を出す**
   - ISPICKVAL などを使って Yes/No や 1/0 に変換し、そこから割合計算
   - 見た目はすっきりときれいに作れる

---

## どれを選ぶべきか？

これはあくまで私見ですが、**一般ユーザーにおすすめしたい順番**は以下のとおりです：

1 → 2 → 3 → 4

というのも、「4」の行レベル数式は作る側から見ると一番楽なのですが、使う側にとっては理解が難しいケースが多いためです。

例えば ISPICKVAL 関数。Salesforce 開発者にとってはよく使う関数でも、一般ユーザーはこの場面でしか触れる機会がなく、応用が効きづらいです。  

それであれば、多少ハードルが高くても PARENTGROUPVAL のようにレポート構造を理解しながら使う関数のほうが、ユーザー本人の学びにもつながり、結果的に運用も安定します。

また、行レベル数式で作った割合計算は、**グルーピング内に分母と分子のレコードが共存してしまい、肝心のレコードレベルの確認が逆にしにくい**という側面があります。

---

## 具体例

PARENTGROUPVAL を使った場合は、グルーピングで2つ以上の選択肢を分けることになります。  

例えば、架電業務で「通電」と「それ以外」の割合を出したい場合。マネージャーが通電率の低い担当者に注目したとき、次に見たいのは「通電したケースの詳細」と「不在だったケースの違い」ではないでしょうか？

このとき、バケット項目と PARENTGROUPVAL 関数を使ったレポートであれば、自然にその流れに向かえます。

一方、行レベル数式を使って「通電した場合だけ 1 を表示するフラグ」を作ったとすると、1 と 0 の値でグルーピングしてまで分析しようとは思わないはずです（見た目も微妙です）。  

その結果、通電と不在の違いを掘り下げるという目的が果たせず、「Salesforceは使いづらい」という印象だけが残るかもしれません。

こうした点から、行レベル数式の便利さは認めつつも、昔からある **PARENTGROUPVAL に沿った集計レポート**を私は推奨しています。

---

## 結論：きちんとした運用設計を

「使いやすいように」工夫するのは大切ですが、それが「後からわかりづらくなる」「運用が破綻する」リスクを増やすのであれば本末転倒です。

見た目が少し不格好でも、使う人のことを本当に考えるのであれば、**設計に則った正攻法**を選ぶべきだと考えます。
FlutterでTabBarのタップ時の色とエフェクトを消してみた

![スクリーンショット 2025-05-31 14.36.03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/672609/4061c05f-2136-47ef-94c6-aa0ae7433f21.png)



# はじめに
TabBarの実装をするときに、タブをタップした時のエフェクトが気になったりしたことはありますでしょうか？
視覚的にタップしたことがわかる点だととてもいいと感じることができますが、個人開発で作成している「FoodGram」のアプリではできるだけエフェクトは使いたくないと考えていました。

# 個人開発のちょっとした紹介

個人開発で「FoodGram」というアプリを開発しています。

FoodGramは、世界中のユーザーと食の楽しさを共有できるフードシェアアプリです。美味しい料理やお気に入りのグルメスポットを記録・共有しながら、みんなでグローバルな「フードマップ」を作りましょう🍜。

https://apps.apple.com/jp/app/foodgram/id6474065183

https://play.google.com/store/apps/details?id=com.food_gram_app.com.com.com


「FoodGram」は、フードシェアアプリとなっており、あなたの好きなレストランの食事をぜひこのアプリで共有していただけると嬉しいです!!



## TabBarのエフェクトを無効化する
ポイントはこの2つになります。


```dart
splashFactory: NoSplash.splashFactory, // リップル無効化
overlayColor: WidgetStateProperty.all(Colors.transparent), // タップ時の色を透明に
```

## 最終的なコード
色々手を加えていますが、ぜひ参考にしていただけると幸いです。

```dart
bottom: TabBar(
  indicatorWeight: 1,
  automaticIndicatorColorAdjustment: false,
  unselectedLabelColor: Colors.grey,
  labelColor: Colors.black,
  indicatorColor: Colors.black,
  indicatorSize: TabBarIndicatorSize.tab,
  splashFactory: NoSplash.splashFactory,
  overlayColor: WidgetStateProperty.all(Colors.transparent),
  enableFeedback: true,
  tabs: <Widget>[
    Tab(
      icon: Icon(Icons.dinner_dining, size: 30),
      height: 38,
    ),
    Tab(
      icon: Icon(Icons.restaurant_menu, size: 30),
      height: 38,
    ),
  ],
),


```


## 実装したUI

実際にタブにエフェクトが表示しないようになっていると思います。やったね。

![ScreenRecording_05-31-2025-午後2-24-25_1.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/672609/a480cba3-33a5-406d-bc26-eb9a3060ae8e.gif)




## 最後に
この内容については自分だけではなく、知り合いのJboyさんとのもくもく会にて実装できました。本当にありがとうございます🙇
オプショナルチェイニング (`?.`) とは

## ✅この記事について
現在TypeScript学習中です！わからなかったことをまとめたので、自分用備忘録を兼ねて記事を作成します。

---

## ✅ 概要
オプショナルチェイニング（`?.`）は、JavaScript/TypeScript の構文で、  
**`null` または `undefined` の可能性があるプロパティに安全にアクセスするための演算子**。

---

## ✅ 書き方と意味

```ts
const value = obj?.prop
```

- `obj` が `null` または `undefined` の場合 → `value` は `undefined` になる（エラーにならない）
- `obj` が存在すれば `obj.prop` の値を返す

---

## ✅ よくある使用例

### 1. ネストしたオブジェクトの安全なアクセス

```ts
const user = { profile: { name: "Alice" } }

const name = user.profile?.name   // "Alice"
const age = user.profile?.age     // undefined
const city = user.address?.city   // undefined（address がないので安全にスキップ）
```

### 2. 配列の要素チェック

```ts
const items = []

const firstId = items[0]?.id  // undefined（items[0] が存在しないため）
```

### 3. 関数の存在確認と実行

```ts
user.printName?.() // 関数があれば呼び出す、なければ無視
```

---

## ✅ よく一緒に使われる構文：Null合体演算子（`??`）

```ts
const result = obj?.value ?? "デフォルト値"
```

- `obj?.value` が `null` または `undefined` のとき `"デフォルト値"` を返す
- `false` や `0` はそのまま使われる（nullish 判定）

---

## ❌ よくある間違い（古い書き方）

```ts
// エラーになる可能性あり（objがnullの場合）
const value = obj.prop.subprop
```

---

## ✅ メリットまとめ

- ネストしたオブジェクトの安全な参照ができる
- 冗長な `if` や `&&` チェーンを省略できる
- 配列・関数・オブジェクトすべてに使える
- コードが読みやすくなる

---

## 💡 注意点

- **プロパティアクセス/関数呼び出しのみに使用可能**
  - OK: `obj?.prop`, `obj?.[key]`, `func?.()`
  - NG: `obj?prop`, `?.obj.prop` など文法誤り
- オプショナルチェイニングは**左側が `null` / `undefined` のみを対象**としている
ブランチは並行宇宙だった！小学生でもわかるように説明してみた

こんにちは。  
前回は「Gitって何？」って話をしたよね。  
今回は、Gitを使うときによく出てくる**「ブランチ」**ってやつについてお話ししようと思うよ！

## まず、1本の物語を考えてみよう

たとえば、君が「勇者の物語」を書いていたとしよう。  
最初はこう始まるんだ。

> むかしむかし、あるところに勇者がいました…

そのあと、Aの展開にしようか、それともBの展開にしようか迷ったとする。

- A案：勇者はドラゴンを倒しに行く！
- B案：勇者は魔法を学びに行く！

どっちも面白そう。どうしよう…

## そんなときに「ブランチ」の出番！

Gitでは、物語（＝コード）の途中から**別の展開を並行して書く**ことができるんだよ。  
それが「ブランチ（branch）」！

つまり、「もしもこうだったら？」っていう別ルートを自由に作れるわけ。  
この仕組み、まるで**並行宇宙**みたいだと思わない？

- `main`ブランチ：元の世界（たとえば「ドラゴンを倒す話」）
- `feature/magic`ブランチ：分岐した別の世界（「魔法を学びに行く話」）

こんな感じ👇

## じゃあ、ブランチは何のために使うの？

たとえばこんなときに便利！

- まだ試し段階のアイデアを別で進めたいとき
- チームで別々の作業を同時に進めたいとき
- 「本番環境に影響を出さずに」安全に作業したいとき

「本のコピーを取って、別のアイデアで続きを書いてみる」ってイメージだね。

## ブランチを作るのはカンタン！

ターミナルでやるなら、こんな感じ！

```
git branch feature/magic     # 新しいブランチを作る
git switch feature/magic     # ブランチを切り替える（または git checkout）
```

あとはそのブランチで好きにコードを書いてOK！  
やっぱり本筋に戻りたくなったら `main` に戻ればいいだけ。

## 最後は「マージ」で合体だ！

別のブランチでいい感じに書けたら、  
「やっぱこれ本編に入れたい！」ってなることもあるよね？

そんなときは「マージ（merge）」っていう技を使って、元の世界（mainブランチ）に**変更を合体**させるんだ！

```
git switch main
git merge feature/magic
```

バシャーン！と宇宙がひとつになるわけだね（ちょっと中二病っぽいけど）。

## まとめると…

- **ブランチ**は「もしも世界」を作る道具！
- ひとつの物語を壊さずに、別のストーリーを自由に試せる
- 最後は「マージ」で1本の流れに合体！

Gitのブランチを使いこなせると、作業が**安心・安全・自由**になるよ！

## おまけ：よくあるブランチ名

| ブランチ名        | 意味                             |
|------------------|----------------------------------|
| `main`           | メインのコード（本編）           |
| `develop`        | 開発中のブランチ                  |
| `feature/◯◯`     | 新しい機能を作るための分岐        |
| `bugfix/◯◯`      | バグを直すための分岐              |
| `hotfix/◯◯`      | 緊急対応用の分岐                  |

どうだったかな？  
Gitの世界、実はちょっとSFっぽくてワクワクしない？  
「コード＝物語」と考えると、意外とイメージしやすいかも！

それじゃあ、またね！🧙‍♂️✨
【Python】仮想環境について

1つのPCに異なるバージョンのPythonパッケージを置くことができます。

「python -m venv ディレクトリ名」のディレクトリ名は省略できません。

仮想環境を無効化するdeactivateコマンドは、どのOSでも同じコマンドを使います。

不要になった仮想環境を削除する場合は、作成したディレクトリを削除しまｓ。
Androidリリースビルドが「成功したのにAPKがない」

Androidリリースビルドが「成功したのにAPKがない」場合の真相と対処ガイド

> 対象：Cordova、Gradle素のAndroid、React Native、Flutterなど、Gradleを使うAndroidプロジェクト。

> 典型症状：コンソールに`BUILD SUCCESSFUL`と出るのに、期待していた`app/build/outputs/apk/release/app-release.apk`が見当たらない。

# 1 問題の現象
```bash
cordova build android --release # または gradlew bundleRelease
```
- ビルドは成功
- ログにはこんな行が出る。
    ```pqsql
    Built the following bundle(s):
        app/build/outputs/bundle/release/app-release.aab
    ```
- 一方で後処理スクリプトがエラー
    ```perl
    ENOENT: no such file or directory, rename '.../apk/release/app-release.apk' ...
    ```
- つまりAABはあるがAPKがない

# 2 ね本原因：デフォルト出力がAPK➡️AABに変わった

|年月|出来事|影響|
| --- | --- | --- |
|2021-8|Google Playで新規アプリはAAB必須|配布パイプラインにAAB対応が必須|
|2021-9|Gradle7/AGP7: リリースビルドのデフォルト成果物をAABに切り替え|`assembleRelease`を呼ばない限りAPKを作らない|
|2021-10|cordova-Android10:`cordova build --release`で`bundleRelease`を実行|引数なしだとAABのみ生成|

> その結果、debug=APK、release=AABが"新しい常識"になった。旧来の「リリースでもAPKを拾う」スクリプトはファイルを見つけられずエラーになる。

# 3 クイック修復策

## 3-1 APKがほしい場合
```bash
cordova build android --release --packageType=apk
```

あるいは
```bash
cd platforms/android
gradlew assembleRelease
```
頻繁に使うなら、`packageType=apk`を固定すると楽。

# 4 システマティックな調査手順

|Step|チェックポイント|コマンド・方法|典型結果|
|---|---|---|---|
|①ビルドタスク|bundleReleaseかassembleReleaseか|./gradlew task --all|grep Release|
|②成果物フォルダ|outputs/bundle/release/ vs outputs/apk/release|ls app/build/outputs/**/release/|どちらにファイルがあるか|
|後処理スクリプト|APKパスをハードコードしていないか|grep -R "\.apk" scripts/||
|④CLI引数|--packageType=が指定されているか|CI ログ/package.jsonを確認|省略時はデフォルト継承|
|⑤Gradle設定|android.bundle.enable...などのフラグ|build.gradleを検索|trueならAABだけ|

# まとめ
「ビルド成功なのに APK がない」はバグではなく エコシステムの進化。
タスク→成果物→スクリプト のチェックリストを持っておけば、
同じ罠にハマっても 2 分で原因を突き止められます。
皆さんのリリースがスムーズに進みますように！
Intel内蔵GPUでDirectXエラーでゲームが起動しない~DXVKを使って解決した話


## はじめに

先日、友人のIntel内蔵GPUを搭載したPCで『BIOHAZARD RE:2 "R.P.D. Demo"』をプレイしようとしたところ、**DirectXに関連するエラー**が表示され、ゲームが起動できないという問題に遭遇しました。

ネットで調べたり、ドライバやDirectXを更新したりと、一般的な対処法を試してみましたが、状況は変わらず。最終的に、「**DXVK**」という互換レイヤーツールをWindowsで活用するという、少し変わった方法で解決できたので、その手順と結果をまとめます。

エラー内容
そのまま起動した時
![2025-06-13_23h21_31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3824887/dce5cae1-f68d-4300-b572-9a489916e97b.png)

DirectX関連のconfigいじって起動した時
![2025-06-15_21h01_38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3824887/2f3d93fd-f3e3-452b-a513-e4a1c20fb4a4.png)

## 試した一般的な対処法（すべて効果なし）

- ゲームファイルの整合性チェック  
- Intel GPUドライバの更新（OEM版 → 公式最新版）  
- DirectX ランタイムの再インストール  
- Windowsのアップデートと再起動  
- ゲームの再インストール  

どれも効果がなく、起動時のDirectXエラーは解消されませんでした。


## 「DXVK」とは？試してみたきっかけ

DXVKは、**DirectX 8/9/10/11のAPIをVulkanへ変換する互換レイヤー**で、もともとはLinuxなどでWindowsゲームを動作させるためのツールです。バイオre2はDX12対応ではありますが、体験版はDX11時代のままなので(もちろんDX12も使えます)DX11で動作できれば問題ないはず。

実は非公式ながら**Windowsでも使用可能**であり、Intel ArcシリーズのドライバのアップデートでDirectX 9のパフォーマンスが向上した時は、DXVKが中に組み込まれていたそうです。

こういった背景もあり、Vulkanに変換すれば、DirectXで発生していたエラーを回避できるのではと考えました。（intelはDX11よりはVulkanの方が得意）


## DXVKの導入方法（Windows）

1. [DXVK GitHubリポジトリ](https://github.com/doitsujin/dxvk)から最新版をダウンロード  
2. ZIPファイルを解凍し、中の `x64` または `x86` フォルダから `d3d11.dll` と `dxgi.dll` を選択  
   ※ ゲームのビット数に合わせて選びます（RE:2は64bitなので通常は `x64`）  
3. それらのDLLファイルを**ゲームの実行ファイル（.exe）と同じディレクトリ**にコピー  
4. ゲームを起動  


## 結果

驚くことに、**DirectXエラーを回避し、ゲームが正常に起動**しました。
この辺りはあまり詳しくないので、動いたという事実のみでとどめておきます。

## 注意点

- DXVKは**Linux向けツール**であり、**Windowsでの使用は非公式・サポート外**です  
- 一部のオンラインゲームなどでは**チートとして検出される**可能性が高いです 
- 環境によって動作しない場合もあります。**自己責任で使用してください**

---

## おわりに

Intel内蔵GPUでゲームをプレイしようとした際に、**DirectX関連の不具合で悩んでいる方**にとって、DXVKはひとつの有力な選択肢になるかもしれません。

公式サポート外であることを理解した上で、状況に応じて試してみる価値はあると思います。
この記事が、同じようなトラブルで困っている方の助けになれば幸いです。

---

## 参考リンク

- 🔗 [DXVK GitHubリポジトリ](https://github.com/doitsujin/dxvk)  
- Steamコミュニティ内の関連トラブル投稿（"RE2 致命的エラー"などで検索）
laravel ✕ OAuth2.0 Socialiteでセッションを使ったログインを実装したらGoogleの認証後にlaravelログイン画面にリダイレクトされてしまう

## 概要

下記の内容を実装した。

https://qiita.com/miriwo/items/9ed45134e6f3d6b41105

Googleでの認証完了後、laravelの`/dashboard`が開いてほしいのに何故か`/login`が開いてしまい困ったので原因を簡単にまとめる。

## 困りごと

https://qiita.com/miriwo/items/9ed45134e6f3d6b41105

こちらの記事の.envのセッションドライバの修正以外を完了し動作確認をしたところ「概要」に記述した問題が発生した。

```.env
SESSION_DRIVER=database
```

だと意図しない挙動になり

```.env
SESSION_DRIVER=file
```

だと意図した挙動になる

## 原因

セッションドライバがdatabaseの場合、設定通りDBのsessionsテーブルを用いてセッションの管理が行われる。
もちろんテーブルで管理しているということはレコードINSERTが行われている。さらにこのレコードINSERTは非同期で行われる事がある。
今回の処理で問題となったのがGoogleからOAuthのトークン類を受け取るlaravel側のリダイレクト系処理部分である。下記のような処理が行われている。

1. リクエスト到着
1. OIDCのトークンID内部のopen id（google_id）を用いてUserinfo APIにリクエスト送信
1. ユーザーデータの取得
1. セッションを使ったログイン
1. セッションにUserinfo APIから返ったユーザーデータを保存
1. `/dashboard`にリダイレクト

`/dashboard`はログイン済みユーザーのみ許容されるルーティングである。

根本的な原因は
「セッションを使ったログイン」が実行されセッション情報がsessionsテーブルにINSERTされる前に`/dashboard`の処理が実行されてしまったことが挙げられる。
先述の通り、セッションドライバがdatabaseの場合、レコードのINSERTが行われ、INSERTは非同期で行われる。さらにDBとのやり取りはI/Oの時間がかかる。
そのためsessionsテーブルにINSERTされる前に`/dashboard`の処理が実行されてしまったっぽい。
カンタンなWebツールはAIに作らせよう

こんにちはAtaroです。この頃暑いですね。とある事情で自転車を30分間こいだのですが、汗びっしょりになってしまいました。昔の6月って暑かったっけ...?

そんなことはさておき、今回は近頃自分が実践しているLLMを用いたカンタンなWebツールの自作について解説していきたいと思います

# カンタンなWebツールならAIで作れる時代

ちょっとした物事とかを解決してくれるWebツールってインターネットにあふれてますよね

文章の文字数を数えてくれるアプリとか、1GBって何MBだっけとか、MarkDownのテーブルをHTMLのテーブルに変換したいとか...etc

今までだったらWebツールをググって使用したりしてたと思うんですが、Webツールってオフラインだと使えなかったり、そもそも業務の機密データを入れたいから使えないなんてことがあってちょっと不便があったかもしれません

でも、令和7年にはそんな悩みはAIによって解消できます！
上記であげた文字数を数えるアプリとかはAIで超カンタンに作れるんです！

# Webツールの作り方

## 基本的の考え方
1. AIにHTMLとピュアなJavaScriptでアプリのコードを書いてもらう
2. それをHTMLファイルにしてブラウザで開く

## 実際のプロンプトを伝授します！

基本的な考え方のまんまをプロンプトとして与えればOK

プロンプト
```
以下のツールをHTMLとピュアなJavaScriptで作成して
（ここに作りたいツールの内容を書く）
```

# 実際に簡単なWebツールを作ってみよう

# 1. 文字数をカウントするツールを作成する

以下のプロンプトを作成して適当なAIに投げ込んでください、大体一発で出来ます

```
以下のツールをHTMLとピュアなJavaScriptで作成して
文字数を数えるツール
```


ChatGPT4oの例

https://chatgpt.com/share/6853fc94-c91c-8013-8af7-94bf673adb88


あとは、できたファイルをメモ帳などでテキストファイルとして保存してから拡張子をhtmlに変えてダブルクリックするだけ

![文字数カウントツール](https://storage.googleapis.com/zenn-user-upload/26a87f867fac-20250619.png)

リアルタイムで文字数を書いてくれるツールがすぐにできました

# 2. Youtubeのプレイリストループ再生ツールを作る

Youtubeで特定の音楽動画を複数プレイリストにしてループ再生したいことありますよね

Youtubeの標準機能でプレイリストを作成してループ再生できますが、ちょっと面倒

でもこういうツールもAIならすぐに作れます!

ChatGPT4oの例
https://chatgpt.com/share/6853fab0-6024-8013-be96-49deec9b8d68


```
以下のツールをHTMLとピュアなJavaScriptで作成して
Youtubeで動画のプレイリストを作成して自動でループ再生するツール
```

![Youtubeプレイリストループ再生ツール](https://storage.googleapis.com/zenn-user-upload/3fadf012066f-20250619.png)

ちょっとこれはすごいですよね...

ものによっては再生できないこともありますが、それは無料の自作ツールの宿命ということで


# あとがき

今回の記事いかがだったでしょうか？

もし、気に入ってくださったり、こんなツールをつくりました！　とかあればコメントやXのDMで教えてくれるとありがたいです

それでは
パワーポイントテンプレート(日記)


```
【タイトル】※フォント：メイリオ、28pt、太字、左寄せ  
AIとは

【図ラベル】※フォント：メイリオ、20pt、中央配置  
ニューラルネットワーク

【箇条書き】※フォント：メイリオ、18pt、左寄せ  
・ニューラルネットの説明

【ページ数】
1 / N
```
非線形常微分方程式と逐次線形化



## 🔷 1. 非線形常微分方程式と逐次線形化

### ✅ 一般系：

$$
\frac{d\mathbf{x}}{dt} = \mathbf{f}(\mathbf{x}, \mathbf{u}), \quad \mathbf{y} = \mathbf{h}(\mathbf{x})
$$

### ✅ 逐次線形化（ヤコビ展開）：

任意時点 \$\mathbf{x}\_0, \mathbf{u}\_0\$ 周りで一次近似：

$$
\frac{d\Delta \mathbf{x}}{dt} \approx A \Delta \mathbf{x} + B \Delta \mathbf{u}, \quad \Delta \mathbf{y} \approx C \Delta \mathbf{x} + D \Delta \mathbf{u}
$$

* \$A = \left.\frac{\partial \mathbf{f}}{\partial \mathbf{x}}\right|\_{\mathbf{x}\_0, \mathbf{u}\_0}\$
* \$B = \left.\frac{\partial \mathbf{f}}{\partial \mathbf{u}}\right|\_{\mathbf{x}\_0, \mathbf{u}\_0}\$
* \$C = \left.\frac{\partial \mathbf{h}}{\partial \mathbf{x}}\right|\_{\mathbf{x}\_0}\$
* \$D = \left.\frac{\partial \mathbf{h}}{\partial \mathbf{u}}\right|\_{\mathbf{x}\_0}\$

### ✅ 制御系設計：

この線形近似系に対して：

* LQR/LQI による最適制御
* オブザーバ設計（カルマンフィルタ含む）
* MPC（Model Predictive Control）など適用可能

---

## 🔷 2. 熱拡散方程式（PDE）の逐次線形化

### ✅ 熱拡散PDE（1次元）：

$$
\frac{\partial u(x,t)}{\partial t} = \alpha \frac{\partial^2 u(x,t)}{\partial x^2} + f(u)
$$

* \$\alpha\$：熱拡散係数
* \$f(u)\$：非線形項（例：反応拡散モデル）

---

## 🔁 空間離散化 ⇒ 無限次元→有限次元（常微分方程式化）

### ✅ 空間離散化（finite difference）：

\$x\_i = i \Delta x,\ u\_i(t) \approx u(x\_i, t)\$

$$
\frac{du_i}{dt} \approx \alpha \frac{u_{i+1} - 2u_i + u_{i-1}}{\Delta x^2} + f(u_i)
$$

→ \$N\$点メッシュにより \$N\$次元の**非線形 ODE 系**

---

## 🔁 非線形ODEへの線形化（逐次）

### ✅ 線形化対象：

$$
\frac{d\mathbf{u}}{dt} = A \mathbf{u} + \mathbf{f}(\mathbf{u}) + \mathbf{B}u_{\text{in}}
$$

を、

$$
\frac{d\Delta \mathbf{u}}{dt} \approx (A + J_f)\Delta \mathbf{u} + B \Delta u_{\text{in}}
$$

* \$J\_f\$ は \$f(u)\$ のヤコビ行列（非線形項の線形化）

---

## 🔧 制御応用：現代制御への接続

* **状態空間化**：\$\dot{\mathbf{x}} = A \mathbf{x} + B \mathbf{u}\$ に変換
* **オブザーバ**：\$L\$を設計し、\$\hat{x}\$ 推定
* **フィードバックゲイン**：\$K\$を設計し、\$u = -K \hat{x} + r\$

---

## ✅ まとめ：非線形・PDEの制御へのルート

| 種類       | モデル                                                | 空間離散化    | 線形化      | 制御適用               |
| -------- | -------------------------------------------------- | -------- | -------- | ------------------ |
| ODE      | \$\dot{x}=f(x,u)\$                                 | 不要       | ヤコビ展開    | LQR, MPC, Observer |
| PDE（熱拡散） | \$\partial\_t u = \alpha \partial\_{xx} u + f(u)\$ | FDM, FEM | ヤコビ + 離散 | 状態フィードバック, MHE     |

---
ラズパイサーバー起動時に自動でdocker compose upする



# 1. やりたいこと


ラズパイを自宅サーバーとして運用していますが、再起動する際にいくつかあるアプリについていちいちdocker compose upするのが面倒なので、systemdから自動起動するようにします


# 2. 手順


以下の手順で設定します
・1.systemd serviceファイルを作成する
・2.serviceを有効にする
・3.serviceを開始する


## 2-1. systemd serviceファイルを作成する


/etc/systemd/system/に拡張子がserviceであるファイルを置くとsystemdサービスとして扱われます。今回はラズパイなのでnanoエディタで作成編集していきます


```terminal:
sudo touch etc/system/hoge.service
sudo nano etc/system/hoge.service 
```


/hoge/ユーザー名/dev/hoge/docker-compose.yml を実行する場合、以下のように書きます。特に説明を受けなくても何をやっているか分かるのが良いですね


```:/etc/systemd/system/hoge.service
[Unit]
Description=Start hoge Docker Compose project at boot
After=network-online.target docker.service
Requires=docker.service

[Service]
Type=oneshot
WorkingDirectory=/home/ユーザー名/dev/hoge
ExecStart=/usr/bin/docker compose up --build -d
RemainAfterExit=true

[Install]
WantedBy=multi-user.target
```


## 2-2. サービスを有効にする


自動起動する為にはenableしておく必要があります


```terminal:terminal
sudo systemctl daemon-reexec
sudo systemctl enable hoge
```


## 2-3. サービスを起動する


次回からシステムが起動するとサービスが実行されますが、現在は起動していない状態ですので以下コマンドで起動しておきます。ここで一度起動しておけば、作成したサービスに不具合があるなどした場合にすぐ分かります


```terminal:terminal
sudo systemctl start rp5_sensor.service
```


## まとめ


簡単ですね
レッツトライ
CertsTimeによって提供される Salesforce‑Sales‑Representative Exam Questions

2025年に向けてSalesforce-Sales-Representative認定取得を目指す方へ
進化するテクノロジー業界に対応した準備ができていますか？CertsTimeでは、2025年版の試験に完全対応した、専門家による検証済みの最新Salesforce-Sales-Representative試験問題集を提供しています。私たちのSalesforce-Sales-Representative試験教材は単なる暗記にとどまらず、実際の試験条件を反映した問題と最新の出題範囲に基づいて作られており、よりスマートで戦略的な学習を実現します。既存スキルのブラッシュアップはもちろん、最新の試験ブループリントで追加されたトピックへの対応にもCertsTimeは力を発揮します。目的を持って、正確に、自信を持って学びましょう。
なぜ2025年版のSalesforce-Sales-Representativeを選ぶべきか？
テクノロジーも試験内容も常に進化しています。2025年版のSalesforce Salesforce-Sales-Representative試験は、業界の最新動向や技術革新を反映した内容にアップデートされています。最新の出題形式やトピックの変更に合わせた学習こそが、実際の試験構造と一致する準備につながります。"
最新版Salesforce-Sales-Representative試験の変更点とは？
2025年の更新では、出題トピック、比重、質問形式に変更があります。シナリオベースの質問や実際のケーススタディ、新しい用語の導入などが含まれる可能性があります。CertsTimeでは、これらの変更点を確実に反映させたSalesforce Salesforce-Sales-Representative試験問題を提供し、予想外の出題に驚かされることがありません。
CertsTimeでリアルなSalesforce-Sales-Representative試験体験を
CertsTimeのSalesforce試験問題は、本番試験の環境を忠実に再現するよう設計されています。制限時間、ひねりの効いたシナリオ、複雑な選択問題（MCQs）など、試験に必要なメンタルと技術の両方を鍛えることができます。

CertsTimeは世界中のSalesforce-Sales-Representative受験者に信頼されています
世界中の受験者が、CertsTimeの認定対策教材を選んでいます。Salesforce Salesforce-Sales-Representativeのダンプや問題集は、認定プロフェッショナルによってレビューされ、品質・関連性・正確性が保証されています。これが、真剣に合格を目指す受験者に選ばれる理由です。
CertsTimeがSalesforce-Sales-Representative教材を常に最新に保つ方法
私たちは常に、Salesforceによる公式更新、試験ブループリント、ユーザーフィードバックを監視しています。Salesforceからの発表があれば、すぐに教材をアップデートし、2025年を通じてSalesforce-Sales-Representative試験問題が常に最新の状態であることを保証しま今すぐ25%割引 – コード：SAVE25を使用
無料デモ問題も利用可能  www.certstime.com/cheat-sheet-salesforce-sales-representative-dumps
CertsTime Salesforce-Sales-Representative試験問題の主なメリット
検証・確認済みの正確な回答

わかりやすい解説付き

PDF形式でオフライン学習が可能

学習時間と労力の節約

すべてのデバイスに対応

これらのメリットは、初回での合格を真剣に目指す学生やプロフェッショナルに最適です。
最後に
2025年版Salesforce-Sales-Representative認定試験に合格するための道のりは、信頼できる、最新で効果的な準備から始まります。CertsTimeを使えば、最新の変更に対応したリソースにアクセスでき、自信を持って合格を目指すことができます。将来を運任せにせず、今すぐ最新の試験問題をダウンロードし、認定取得への第一歩を踏み出しましょう。
「パスワード握りしめてた時代、終わりにしない？」――Kerberos認証の深淵をのぞいた話

---

「パスワード握りしめてた時代、終わりにしない？」――Kerberos認証の深淵をのぞいた話

はじめに

正直に言う。
最初にKerberosの図を見たとき、「は？」ってなった。

なんか横文字ばっかりで、チケットだのKDCだの、映画のチケット売り場みたいな話してきて、しかも「安全な通信がどうこう」って。

でも、冷静に考えたら、パスワードを何度もサーバに投げるような世界がヤバいのは明らかで。
それをどうにかしたくて生まれたのがKerberosっていう認証プロトコルだった。

この記事は、そんなKerberosの「何がすごいのか」「どこがややこしいのか」「実際どう動いてるのか」を、僕なりに咀嚼して吐き出した記録です。
パスワードを大事に思うすべてのエンジニアに捧ぐ。


---

Kerberos認証って何なん？

一言でいうと、**「パスワードを直接やり取りしないで済むようにする仕組み」**です。

しかも、ただの仕組みじゃない。
Active Directory、LDAP、NFS、Linuxログイン…ありとあらゆる場所にしれっと使われてる、セキュリティの裏番長みたいなやつ。

名前の由来はギリシャ神話の地獄の番犬、ケルベロス（三つ首の犬）。
三つ首ってのは、Kerberosの構成要素が3つあることから来てる。

クライアント（ユーザー）

サーバ（サービス）

KDC（Key Distribution Center）


このKDCってのが最強で、信頼のド真ん中に君臨してる。
「KDCを信じる者は救われる」、そんな世界線の話。


---

全体像：チケットのキャッチボールで認証する

Kerberosはチケットを使う。電車の切符みたいなやつ。

ざっくり流れを書くとこう：

1. ユーザーはログイン時にKDCへ認証要求を出す（AS Exchange）


2. KDCは「TGT（Ticket Granting Ticket）」というチケットをくれる


3. ユーザーはTGTを持って、今度は「使いたいサービスくれ」とKDCにお願いする（TGS Exchange）


4. KDCはサービス用のチケットをくれる


5. それを持って、ようやくサービスにアクセスできる（AP Exchange）



ここでのポイントは、パスワードを投げるのは最初の1回だけってとこ。

あとは**「チケットあるんで…」って顔パスで進んでいける**。
この「顔パスの仕組み」がセキュリティ的にすごくて、通信中にパスワードは出てこないし、盗まれにくい。


---

TGTとTGS：ふたつのチケットの意味

初心者がつまづくポイントNo.1、それがこの**「TGT」「TGS」って何が違うんや」問題**。

簡単に言うと：

TGT（Ticket Granting Ticket）：KDCに「サービス用チケットをください」とお願いするための通行証。

TGS（Ticket Granting Service）チケット：実際にサービス（ファイル共有とか）を使うための切符。


例えるなら、TGTは「遊園地の入場券」、TGSは「アトラクションに乗るための券」。

「一回TGTをもらったら、あとはそれ使っていろんなTGSをもらえる」＝シングルサインオンが実現できる。


---

認証処理の裏側：なにがどう安全なのか？

じゃあ「なんで安全なのか？」って話。
ここからがKerberosのカッコいいところ。

鍵は「共通鍵暗号」でやり取りされる

Kerberosは基本、**共通鍵暗号（＝お互いに知ってる秘密の鍵で暗号化）**で動いてる。

たとえば、最初のログイン（AS Exchange）では、ユーザーがKDCに「こんにちは」って言うと、KDCはTGTとセッションキーを返してくる。

でもそれ、「ユーザーのパスワードから導いた鍵」で暗号化されてる。
つまり、パスワードを知らなきゃ復号できない＝TGT使えない。

一方、TGSをもらうときも、「TGTと一緒にセッションキーを送る」ことで、本人確認ができる。
そして、最終的にサービスにアクセスするときも、そのセッションキーを使って通信が暗号化される。

リプレイ攻撃への耐性もある

Kerberosは「タイムスタンプ」をめちゃくちゃ大事にしてる。
TGTやTGSには有効期限があるし、通信にも時間情報が含まれる。

これは何を防ぐかっていうと、「誰かが昔のチケットをコピーして悪用する」みたいな攻撃（リプレイ攻撃）。
時計がズレてたら認証通らないし、1回限りの使い捨てチケットで回すから、安全性が高い。


---

Kerberosの苦しみ：実装と運用のリアル

いいことばっかり書いたけど、現実はちょっと違う。

Kerberosの最大の敵、それは**「時刻同期」**。

KDCとクライアントで時計がズレてたら、認証が通らない。
5分ズレてるだけでアウト。NTTよりも正確さを求められる世界。

あと、KDCが一つしかなかったら、そこが落ちた瞬間、認証もサービスも全部止まる。
だから冗長構成が必須だし、設定もそれなりにめんどい。

でも、それでもKerberosは使われ続けてる。
なぜなら、「パスワード握りしめて生きていく世界」から卒業させてくれるから。


---

まとめ：Kerberosは地味だけど偉大

最後にもう一度だけ言わせてほしい。

Kerberosは派手さはないけど、めちゃくちゃ偉い。
地味に、こっそり、でも確実に、僕らのログインやサービス利用を支えてる。

最初は「覚えるのだるっ」って思うけど、
噛めば噛むほど、味が出る。運用すればするほど、有り難みがわかる。

だからこそ、一度ちゃんと向き合っておくべきだと思う。


---

おまけ：Kerberos理解チェック（クイズ）

1. TGTとTGSの違い、説明できる？


2. パスワードが直接通信されない理由、わかる？


3. 時刻同期がズレるとどうなる？


4. KerberosがSSOを実現できる理由は？




---

最後に

この世界には、ユーザーのパスワードを何度もサーバに投げつけてるような危ういシステムがまだまだある。
でも、Kerberosはその不安を「一枚のチケット」に変えてくれる。

もしあなたが今、SSOやLDAPに触れ始めたエンジニアなら。
一度くらい、地獄の番犬と向き合ってみても、いいんじゃないだろうか。
propsの型を再利用するためのPickの使い方（React + TypeScript）

### 背景

Reactではコンポーネント同士で同じようなデータ（props）をやりとりすることがあります。

たとえば「テキストボックスで入力を受け取る型」などを複数の場所で使いたいとき、同じ内容を繰り返し書くのではなく、**1つの型を元に必要な部分だけを取り出して使いたい**場合があります。

このときに便利なのが、TypeScriptの `Pick` という型ユーティリティです。

### Pickとは

`Pick` は、ある型から一部のプロパティだけを抜き出して新しい型を作るものです。

https://typescriptbook.jp/reference/type-reuse/utility-types/pick


```ts
type FormProps = {
  input: string;
  onInputChange: (e: React.ChangeEvent<HTMLInputElement>) => void;
  onSearch: () => void;
  error?: string;
  placeholder: string;
  isLoading: boolean;
  formRef: React.RefObject<HTMLFormElement | null>;
};

// 一部のpropsだけ使いたい場合

type ModalProps = Pick<FormProps, "input" | "onInputChange" | "onSearch" | "error" | "isLoading">;
```

このように書くと、`ModalProps` は `FormProps` の中から、指定したプロパティだけを持つ型になります。

### どんな時に使うか

* すでに定義されている型が大きすぎて一部だけ使いたいとき
* 再利用可能なprops型を部分的に別のコンポーネントで使いたいとき
* 型の重複定義を避けて、変更に強い構成にしたいとき
* 複数のコンポーネントで共通のロジックを共有するが、必要なpropsが完全には一致しないとき

Pickは「全部じゃなくて必要なものだけ欲しい」場面で有効です。


このようにすると、共通の型を無駄なく使いまわしながら、独自の機能も追加できます。

### まとめ

```tsx
type 新しいprops = Pick<元にnprops, "抽出されたtype01" | "抽出されたtype02"> & {
  新しいpropsで追加したい型;
};
```

* 複数のコンポーネントで同じようなpropsを使うなら、型を再利用した方が安全で効率的
* `Pick` を使えば、必要な部分だけを切り出して新しい型にできる
* `&` を組み合わせれば、共通のprops + 独自のpropsの構成も可能

このようにして、propsの重複や定義ミスを減らしつつ、型の一貫性を保つことができます
Salesforce認定 Development Lifecycle and Deployment Architect 合格体験記

## 自己紹介
こんにちは。キタクマです。  
先日Development Lifecycle and Deployment Architect試験（以下、DL&DA）を受験し無事合格したため、私が実践した学習方法をシェアできればと思います。  
軽く自己紹介をさせてください。  

私はSES企業に勤めていて約2年半Salesforceエンジニアとして活動しています。  
業務内容としてはApexの設計、開発やフローの開発もしています。  
受験前の保有資格は
- アドミニストレーター
- 上級アドミニストレーター
- Platform Developer
- Sales Cloud コンサルタント

で、日々の業務を通じてSalesforceに関する知識やスキルを幅広く身につけてきました。　　

今回、DL&DAの資格を受験した理由は将来的にCTA（Salesforce認定テクニカルアーキテクト）を目指しているためです。  
その足がかりとして、まずは取得しやすそうなDL&DAから着手することにしました。

## スコア内訳
DL&DAの合格ラインは65%です。  
私のスコアはちょうど65%（39問正解）での合格でした。  
各分野の得点内訳は以下のとおりです。

| 分野名               | 配点       | 正解数         |
| ----------------- | -------- | ----------- |
| アプリケーションライフサイクル管理 | 8%       | 3           |
| 計画                | 13%      | 6           |
| システム設計            | 15%      | 8           |
| 構築                | 14%      | 4           |
| デプロイ              | 14%      | 5           |
| テスト               | 13%      | 5           |
| リリース              | 13%      | 4           |
| オペレーティング          | 10%      | 4           |
| **合計**            | **100%** | **39（65%）** |

あと1問間違えてたら不合格でした...ｱﾌﾞﾅｲ

## 学習方法・学習スケジュール
学習の最初のステップとして、Salesforce試験ではお決まりの[公式ドキュメント](https://trailhead.salesforce.com/ja/help?article=Salesforce-Certified-Development-Lifecycle-and-Deployment-Architect-Exam-Guide)で試験の概要を把握しました。  

続いてドキュメントに記載の試験対策のTrailheadを活用しました。  
モジュールとドキュメントを読み込む作業です。  

次に、有料の問題集を活用してアウトプット中心の学習に切り替えました。  
ここではどの問題集を使ったかは割愛します。  
問題集を解くうえで意識したのは単に正解・不正解を確認するだけでなく、不正解の選択肢についても「なぜ間違いなのか？」を自分の言葉で説明できるように考えるという方法を徹底しました。  
これにより、単なる暗記ではなく、実務にも応用できる理解が深まった気がします。  

上記の勉強を約2週間と比較的短期間で集中的に取り組みました。  
渡しの場合、だらだらと時間をかけてしまうと忘れたり、モチベーションが下がってしまうと感じていたため、短期集中型の戦略を取りました。  

勉強のタイミングは、平日は業務終了後に1時間程度を確保し、さらにスキマ時間（トイレ中や昼休み）を活用してスマホで問題集を解くことで、時間を有効に使いながら理解を定着させました。

## 合格のコツ
実際に試験を受けて感じたのは「問題集だけでは太刀打ちできない問題が多く出題された」ということです。  
問題集には無い問題が多く出題されギリギリの点数となってしまったため、Trailheadの解説やSalesforceの公式ドキュメントをよく読み込み、出題範囲はすべて広くカバーしたほうがいいと思います。  

また、個人的に難しいと感じたのはMetadata APIとTooling APIの使い分けに関する出題です。どちらも知識としては理解していたつもりでも、実際に使いどころや制限事項を問われると迷うケースが多く、理解の浅さを実感しました。  
復習する必要がありそうです。。。

## 最後に
DL&DAは、開発者や管理者がワンステップ上を目指す上で非常に良い資格だと思います。　　
今後SFにもDevOpsの波は避けられないかと思うので、取っておいて損は無いかと（受験料が高いですが。。）  
ただ、出題範囲も広く、単なる知識の寄せ集めでは合格できない構成になっているため、実務経験と体系的な学習の両輪が重要だと感じました。  
CTAを目指す方はもちろん、プロジェクトで構成管理やリリース戦略に携わる方にも、間違いなく価値のある資格だと思います。
Sayuri Sayings: 日本語リスニングを楽しむポッドキャストの魅力

# Sayuri Sayings: 日本語リスニングを楽しむポッドキャストの魅力

日本語を学ぶ上で、会話の理解は非常に重要ですが、時には難しさを感じることもあります。そんな時に役立つのが、Sayuri Sayingsというポッドキャストです。今回はこのポッドキャストの内容と魅力について詳しくご紹介します。

## Sayuri Sayingsとは?
Sayuri Sayingsは、日本人の先生や友人とのリアルな会話を通じて、日本語のリスニングスキルを向上させることを目的としたポッドキャストです。聞き手にとってわかりやすい表現を用いながら、日常生活や日本での暮らしについてのエピソードをシェアしています。

### ポッドキャストの内容
Sayuriさんが制作するコンテンツには、以下のようなものがあります:
- 日本人との会話動画
- 日常生活や日本での経験を語るエピソード

## なぜSayuri Sayingsを選ぶべきか?
このポッドキャストには、以下のような魅力があります:
- **リスニングに最適**: わかりやすい日本語で話すため、リスニング練習にぴったりです。
- **リアルな会話**: 実際の日本人との会話を聞くことで、自然な言い回しやイントネーションを学べます。
- **プライバシーの尊重**: Sayuriさんはプライベートを大切にしつつ、信頼感のあるコンテンツを提供しています。

## 親しみやすさと信頼感
Sayuriさんが顔を出している理由は、視聴者との親しみや信頼感を高めるためです。顔が見えることで、リスナーはより身近に感じることができ、より深い関係を築けるでしょう。

## 最後に
Sayuri Sayingsは、日本語を学ぶ上での新しいアプローチを提供してくれます。リスニングスキルを向上させたい方や、日本の文化をより深く理解したい方にとって、非常に有益なリソースとなるでしょう。ぜひ一度聞いてみてください！

---

このポッドキャストについての詳細や最新エピソードは、[Sayuri Sayingsの公式サイト](https://example.com)でチェックしてみてください。

## 続きを読む

全文を読みたい方は、[〇〇に登録してください。](undefined)
M5Stack(UIFLOW)とProcessingとのシリアル通信メモ

M5はUIFLOWで開発する派な人向けシリアル通信の方法

参考：[Qiita【Unity】M5Stackというデバイスを、UIFlowでUnityとシリアル通信してみました](https://qiita.com/kiku09020/items/3fb9d5ea41905f2eff9e)




# M5Stack(UIFLOW)
![ss_img 2025-06-19 20.11.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/191122/9b2d6cc8-d091-41c0-a4d1-edd5afb10d81.png)

送信ピンを1、受信ピンを3に設定するとUSBシリアルになるらしい。

# Processing

```Java
import processing.serial.*;
Serial myPort;

String strData = "";
int data = 0;

void setup() {  
  String portNames[] = Serial.list();
  for (int i=0; i< portNames.length; i++) {
    println("[", i, "] ", portNames[i]);
  }
  myPort = new Serial(this, portNames[0], 115200);//シリアル通信の設定、通信速度をArduino側と合わせる
  myPort.bufferUntil('\n');//改行が来たら serialEvent()を呼び出す
}

void draw() {
}


void serialEvent(Serial myPort) { //シリアル通信を受信した時の処理
  strData = trim(myPort.readStringUntil('\n'));  //改行まで読み込み
  data = int(strData);  // 数値に変換
  println(data);
}

```

portNamesの番号は、自身の環境に合わせてM5の接続ポートの番号を入れてください。
【Laravel】正規表現バリデーションの個別エラーメッセージを丁寧に設定する方法

# 概要
Laravelで regex バリデーションを使うとき、エラーメッセージをそのままにしておくとこんな表示になりがちです：
```php
「postal code に正しい形式を指定してください。」
# validation.phpで、「'regex' => ':attributeに正しい形式を指定してください。'」とあるため。
```
しかし、どこがどう「正しくない」のか」がわからず不親切です。
この記事では、郵便番号・登録番号・電話番号（固定・携帯）に対して
わかりやすく丁寧な個別エラーメッセージを設定する方法を紹介します。



# 使っている環境
Laravel 9.x〜10.x（FormRequest 使用）



# 実装場所：FormRequestクラス
```app/Http/Requests/UpdateReceiptSettingRequest.php
    public function rules()
    {
        return [
            'postal_code' => ['required', 'string', 'regex:/^\d{3}-\d{4}$/'],
            'address_line1' => ['required', 'string', 'max:255'],
            'address_line2' => ['nullable', 'string', 'max:255'],
            'issuer_name' => ['required', 'string', 'max:255'],
            'issuer_number' => ['nullable', 'string', 'regex:/^T\d{13}$/'],
            'tel_fixed' => ['nullable', 'string', 'regex:/^\d{2,4}-\d{2,4}-\d{3,4}$/'],
            'tel_mobile' => ['nullable', 'string', 'regex:/^0[789]0-\d{4}-\d{4}$/'],
            'responsible_name' => ['required', 'string', 'max:255'],
        ];
    }

    // 個別エラーメッセージ
    public function messages()
    {
        return [
            'postal_code.regex' => '郵便番号は「123-4567」の形式で入力してください。',
            'issuer_number.regex' => '登録番号は「T」+13桁の半角数字(例：T1234567890123)で入力してください。',
            'tel_fixed.regex' => '固定電話は「03-1234-5678」の形式で入力してください。',
            'tel_mobile.regex' => '携帯電話は「090-1234-5678」の形式で入力してください。',
        ];
    }
```
![スクリーンショット 2025-06-19 19.59.55.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3726068/fad67ab8-081f-40b9-bc13-40cbc12795fd.png)



# なぜ regex に個別メッセージが必要か？
Laravelは regex のバリデーションエラーをすべて：
```
:attribute に正しい形式を入力してください。
```
としか返しません。
これだと「どこが間違ってるの？」がわかりづらく、
ユーザー体験が悪化します。



# 補足：attributes() も使う
'regex' 以外の 'required' などのバリデーションエラーで、
name属性が英語のままになるのを防ぐ。
```/Applications/MAMP/htdocs/Laravel/easy_doc_maker/lang/ja/validation.php
'attributes' => [
    'postal_code' => '郵便番号',
    'address_line1' => 'メールアドレス',
    'address_line2' => 'メールアドレス',
    'issuer_name' => 'メールアドレス',
    'issuer_number' => 'メールアドレス',
    'tel_fixed' => 'メールアドレス',
    'tel_mobile' => 'メールアドレス',
    'responsible_name' => 'メールアドレス',
],
```
![スクリーンショット 2025-06-19 19.59.13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3726068/12b59eee-32b1-4464-b661-bcb7b3a7424d.png)
テクノロジー倫理とアウトソーシング：信頼される開発パートナーとは

AI、ビッグデータ、クラウドコンピューティング――
 デジタル技術の進化により、私たちは今、かつてないスピードで社会を変革しています。こうした変化の中で、アウトソーシングの在り方も大きく進化しつつあります。
単に「コストを下げるための手段」から、「イノベーションを共創する戦略的パートナー」へ。
そして今、**アウトソーシングにおいて最も重要視される要素の一つが「テクノロジー倫理」**です。

なぜ今、「テクノロジー倫理」が問われるのか？
近年、AIによるバイアス問題や、個人情報の不正流用、環境負荷の高いITインフラなど、テクノロジーそのものが社会課題と深く関わるようになってきました。
企業が持続的に成長するためには、単なる技術力だけではなく、倫理的な姿勢と社会的責任が不可欠です。
特にアウトソーシングにおいて注目される倫理的観点：
データプライバシーとセキュリティ
 → 顧客・ユーザーの情報をどのように管理・保護するのか
AIの公平性と説明責任
 → 意図しない差別や偏りを生まないような設計と運用
持続可能性（サステナビリティ）
 → クリーンエネルギーやリモートワークの推進など環境への配慮
多様性と包括性（ダイバーシティ＆インクルージョン）
 → 様々な文化や背景を持つ人々が働きやすい環境づくり
地域ごとの法令遵守
 → ベトナム、EU、日本などの法規制への適切な対応

信頼できる開発パートナーの条件とは？
それでは、企業がアウトソーシング先を選定する際に、「信頼できる倫理的なパートナー」とはどのような存在なのでしょうか。
以下のような観点からパートナーを評価する企業が増えています：
✅ 倫理観のある文化と体制
プライバシーポリシーやAI倫理ガイドラインが整備されているか
従業員のIT倫理教育が定期的に行われているか
情報セキュリティマネジメント体制（例：ISO 27001）を整備しているか


✅ プロダクトにおける倫理的配慮
開発時にアルゴリズムの偏りや倫理リスクをチェックしているか
UI/UX設計において、年齢・文化・身体的特性などに配慮されているか
サステナブルな開発ライフサイクルを意識しているか



GITSが考える「未来志向のアウトソーシング」
私たちGITSは、単に機能を開発する「請負先」ではなく、**お客様と共に未来を創る「パートナー」**でありたいと考えています。
GITSの取り組み：
AI倫理に対応した開発プロセスの導入
 → バイアス分析、トレーサビリティの担保、モデルの透明性強化
個人情報保護への徹底対応
 → ベトナム国内法とGDPRを両立するセキュリティ管理体制
多様な人材と働き方の推進
 → 女性エンジニアの活躍支援、リモート・フレックス文化の醸成
長期的なパートナーシップの重視
 → ビジョン理解から戦略・PoC開発・本番導入まで並走



「どう作るか」が競争優位になる時代へ
2030年に向けたソフトウェア開発の未来では、「早く」「安く」作るだけでは競争に勝てません。
 問われるのは**「誰と作るか」「どう作るか」**です。
信頼される開発パートナーとは、技術力と倫理観の両立を追求する企業。
私たちGITSは、そうした価値観を共有するお客様と共に、より良い社会とテクノロジーの未来を創造していきます。

ソフトウェア開発のご相談はこちら 
https://gits.com.vn/ja/
【PHP】PDOのプリペアドステートメントのプレースホルダーについてのTips

### 環境
PHP：7系
DB：SQLServer
現象：プリペアドステートメントのバインドでエラーになる。

### 前提
データベースの環境がSQLServerの場合に今回の事象が発生しました。
ちなみにPostgreSQLの環境ではほぼ発生しないと思われます。

#### 発生するエラーの例
〜 COUNT field incorrect or syntax error in 〜


#### サンプルコード
```PHP
$user_code = '001';

$user_name = 'taro';

$con = new PDO ("sqlsrv:Server=localhost;Database=testdb", "UserName", "Password");


$sql = <<< SQL

            INSERT INTO
                test_table
        
                (
                    [登録者コード],
                    [登録者名],        
                    [変更者コード]
        
                )
            VALUES
                (
                    :user_code,
                    :user_name,
                    :user_code
                );
SQL;

$hash = [
            ':user_code' => $user_code,
            ':user_name' => $user_name
];

$stmt = $con->prepare($sql);

foreach($hash as $key => $val) {

    $stmt->bindValue($key, $val, PDO::PARAM_STR);

}

$stmt->execute();

```

この時、登録者コードと変更者コードは同一の値をバインドしたいので、どちらも「':user_code' => $user_code」
でいいのですが、実はこれだとエラーになります。

### 解決策
プレースホルダーの名前をそれぞれ別のものに設定すれば解決します。

#### 現状
```PHP
            VALUES
                (
                    :user_code,        
                    :user_name,
                    :user_code
                );

$hash = [
            ':user_code' => $user_code,
            ':user_name' => $user_name
];                
```

#### 修正後

```PHP
            VALUES
                (        
                    :created_by,        
                    :user_name,        
                    :updated_by        
                );

$hash = [
            ':created_by' => $user_code,
            ':user_name'  => $user_name,
            ':updated_by' => $user_code
];                

```

上記のようにそれぞれ別のプレースホルダー名に修正することでエラーが無くなります。

実装していた時、AIツールに質問したら「':user_code' => $user_code,」のように一回の記述で複数のプレースホルダーにバインドするという答えが返ってきたがその後エラーになってしまったので、その後色々と調べた結果今回の箇所がエラーの原因だったことに気が付いた。

今回は以上になります。ありがとうございました:relieved:
初学者に送る「プログラミングの心構え」

# はじめに
プログラミングを始めて5年、IT系のお仕事に就いて丸2年が経ちました。人に教えることも増えてきた中で、プログラミングを学び始めた人の多くがつまづく箇所が見えてきたように思います。

それは、**「参考書や教材と違うケースには対応しきれない」「エラーが出た時・行き詰まった時に解決できない」** といったところです。

学び始めのインプット段階では、技術書や動画教材があるため、勉強がはかどるものの、いざ実践となるとできなくなってしまう…という方が多いように見受けられます。

そのため、この記事では **「より実践力や自走力を上げるにはどうしたら良いか」という勉強の指針や心構えのようなものを紹介したい** と思います。

# 対象読者
- 本やUdemy等でプログラミングに関するインプットが一通り完了した後、次の一手に悩んでいる人
- 写経やサンプルプログラムのコーディングはしたことがあるが、自作プログラムは作ったことがない人
- プログラミングの勉強をしたが、挫折した人
- etc ...

# 心構え1. 検索グセをつけよう！
何か分からないことがあった時、まず検索する癖をつけましょう。

「何を検索すべきか分からない」という時は、「何が分からないのかすら分からない」状態であることが多いので、検索ワードを考えることが頭の整理に繋がることもあります。

まずは**分からないことが何かを明確にして、検索ワードにして調べてみましょう。**

:::note info
「考えてみても検索すべきことが分からない…」という時は、Chat GPTのような生成AIに相談してみてください。ごちゃごちゃな相談も上手く受け取って言語化・助言してくれることが多いです！(心構え3も参照)
:::

# 心構え2. エラーメッセージはまずググれ！
何かエラーが発生すると、大量のメッセージが表示されるかと思います。そのメッセージのうち、たいてい一番下にクリティカルなエラー内容が書かれているので、それをコピペして検索してみましょう。

**何らかのブログや技術記事、質問サイト等から解決策が見つかる確率が高いです。**

# 心構え3. Chat GPTに相談しよう！
心構え1でも少し書きましたが、生成AIに対話形式で相談するのも有効です。頭の整理にもなるし、コードも書いてくれることがあるので大変便利です。

「頭がごちゃごちゃでどうしたら良いか分からない...」「分からないことが多すぎてどこから手を付ければ良いか分からない...」「エラーメッセージを検索してみたけど、情報がほとんどない...」等のケースで活躍します。


:::note warn
生成AIはたまにミスをするので、嘘のコードを提示してくることも…
ファクトチェックしつつ、うまく付き合いましょう
:::

# 心構え4. 怪しいところは結果を細かく出力しよう！
いわゆる「デバッグ」の操作です。
一気にコードを動かすと、どこで引っかかっているのか、どこで予想外の挙動をしているのかが分かりにくいです。そのため、細かい単位で気になるところを出力しましょう。

デバッグツールがあるケースもありますが、まずは一番最初に習うであろう文字列出力関数（pythonなら`print`、C言語なら`printf`のようなもの）を活用するのがおすすめです。

慣れてきたらデバッグツールを活用するのも良いと思います！

# 心構え5. 最低15分は自分で考えよう！
 **「質問する前に最低でも15分は考えよう」** ということです。
 （某質問サイトに「15分考えて分からなかったら質問しよう」的なことが書いてありましたが、その裏返しですね）

 分からないことが出てきたときに、すぐに誰かに聞いてしまったり、諦めてしまったりすると、その場では何とか乗り切れても次に同じようなことがあったときに自分で解決できなくなってしまいます。

苦しいかもしれませんが、まずは自力で考えるようにしましょう。考える際に上述の心構えたちを活用していくと、15分で何かしら解決に近づく一歩を踏み出せることが多いと思います。

# 心構え6. 諦めず挑戦しよう！
急に根性論っぽくなってしまいましたが...結局は諦めない精神が大切だと思います。

自分のレベル感にあった勉強やアウトプットも大切ですが、**実践力を身に着けるには一見難易度が高いように見えることにも挑戦していくことが一番かと思います。**

「時間がかかりそうだからいいや...」「自分には無理そうだから...」と諦めてしまいたくなるところですが、ここで踏ん張ることができると「自律してプログラミングできるようになる」状態に大きく近づくと思います。

# まとめ
自分自身の勉強経験・人を教えた経験から、効果があると思われる心構えを紹介しました。
いささか根性論的な側面もあるかと思いますが、この心構えを持ってプログラミングに向きあうと、脱初心者の一歩を踏み出せるかと思います。

ぜひ参考にしてみてください。
チームで機能するチケット管理のルール集【Backlog想定】現場の知見まとめ

ソフトウェア開発や業務改善において、タスクや課題をどう管理するかは非常に重要です。  
この記事では、**私自身が現場で試行錯誤しながら見出した「チケット管理の運用ルール」** を共有します。

---

## はじめに：背景とこの記事の位置づけ

私が現職に入社したとき、**チケットと紐づかないコミットが大量に存在し、チケット管理が崩壊している状態**でした。  
チケットが形骸化し、進捗も把握できず、誰が何をやっているのか分からない——そんな現場から出発して、  
**独学で運用ルールを整備し、チーム全体に定着させるまでに至った実践的な知見**をまとめたのが本記事です。

対象：**5〜10人程度のチーム**  
ツール想定：**Backlog（本記事ではBacklogを主に想定しています）**

---

## なぜチケット管理が重要か

みなさん一度は、誰にも共有されていないタスクや、納期だけ伝えられる謎のExcel管理に遭遇したことがあるのではないでしょうか？  
特定の人の「懐で温められていた」ようなタスクが、急に振られる——これはチームとして非常に非効率です。

課題管理は、**チーム全員が見える場所で行うべきもの**です。  
そして、見える化することで、ミスや認識のズレにもすぐに気づけるようになります。  
まずは誰もが確認できる状態にすること、つまり「可視化すること」が何より重要です。  
私はその手段として、**チケット管理を強く推します**。

なぜなら、チケット管理には以下のようなメリットがあるからです：

- 抜け漏れの防止  
- タスクの可視化  
- チーム内の認識合わせ  
- 履歴を残すことで経緯を追える  

チケット管理は単なるToDoリストではなく、  
**認識の土台かつチーム間の共通言語**として機能します。

---

## チケット管理の運用ルール

### ✅ 思いついたらすぐにチケットを切る

「これは軽いメモ程度かな？」と思っても、**まずはチケットに残す習慣**をつけましょう。  
後から精査・補足すればよく、**完璧さより記録を残すこと**が優先です。

---

### ✅ 対応しない課題も削除しない

**「対応しない」と判断した経緯こそ重要な資産**です。  
削除せず、却下理由を明記して残しておくことで、**同じ議論を繰り返さずに済みます**。

---

### ✅ 親子課題を活用する

大きな作業は親チケットにし、**タスク単位で子チケットに分割**しましょう。  
ツールに孫課題の機能がない場合は、**タグや命名規則で関係性を明示**するのも有効です。

---

### ✅ チケット起点で議論する

**まずチケットを作る → 議論する → 結論を追記する**という流れを徹底することで、  
記録性と透明性が担保されます。  
**チケットがないまま話を進めるのは原則NG**とするのが理想です。

---

### ✅ チケット粒度は「数時間〜1日以内」

**1チケット = 1目的・1作業**が原則です。  
進捗は「何％」よりも、**子チケットの完了数**で可視化しましょう。

---

### ✅ 会話もチケットベースで行う

「どこまで終わってる？」「あれ対応した？」は、**必ずチケット番号かタイトルで話す**習慣を。  
属人的な認識ズレを防ぎ、記録性も担保されます。  
**チケットにない作業は存在しない**くらいの意識が理想です。

---

### ✅ お客様からの問い合わせもチケット化する

Backlogなどを使っている場合、**問い合わせフォーム → API → チケット登録**の流れを自動化すると抜け漏れ防止に。  
また、**テンプレートの整備**は必須です。  
ITに不慣れな方でも書けるように、**項目を明示したフォーム**を用意しましょう。

---

### ✅ ステータスはチームで統一して使う

Backlogをベースとしたステータス設計の一例：

| ステータス   | 説明                                                                 |
|--------------|----------------------------------------------------------------------|
| 未対応        | 着手前                                                              |
| 仕様問題      | 仕様上実現不可能。対応不要と判断してクローズ                                     |
| 保留中        | コメント待ちや一時中断中                                                       |
| 凍結中        | 現時点で対応予定はない（将来的に検討する可能性あり）                               |
| 差し戻し       | テストNGなどにより、対応者へ再作業指示された状態                                  |
| 処理済み       | 実装完了済み。ただしデプロイや確認作業は未実施                                     |
| デプロイ済み   | 開発環境にデプロイ済み（テスト未着手 or テスト中）                                |
| 打鍵中        | テストチームが検証中                                                       |
| 完了          | 実装・確認・デプロイ含めてすべて完了、または対応しないことが正式に決定済み                   |

---

## よくある失敗パターン（アンチパターン）

- 粒度が大きすぎて誰も追えないチケットを放置  
- 実装内容が変わってもチケット名を直さず、「何の対応か分からない」状態に  
- 1つのチケットに複数修正を詰め込みすぎてクローズできない  
- チャットや口頭だけで依頼してしまい、**記録が残らず責任も曖昧に**

---

## おわりに

すべての作業や認識は、文章にしてチケットで残すことが本当に大切です。  
口頭だけのやりとりでは記録が残らず、誰が何を決めて、どう動いたのかが曖昧になります。  
一方、チケットに残しておけば、過去の経緯をたどることができ、類似課題の再利用やナレッジ共有にもつながります。

「文章に残す」「チケットで管理する」――この基本を徹底することで、  
属人性を排除し、チームとしての一貫性と再現性が生まれます。

チケット管理の仕組みは、一度崩れるとチームの信頼や運用が破綻しかねません。  
しかし逆に言えば、ほんの少しのルールと意識の共有だけで、チームがスムーズに回り始めるのも事実です。

完璧を目指す必要はありません。  
まずは、「気軽にチケットを切ること」から始めてみてください。
pyenv＋venvでAmazon Linux2にPython仮想環境を構築する

pyenvとvenvを使ってPythonの仮想環境を構築してみた時の記録です。

・pyenvで色々なバージョンのPythonを使い分ける
・venvでAnsibleバージョンX.X.X用の仮想環境を使い分ける
を目的として、環境構築してみました。

## 前提条件
- 利用環境：Amazon Linux2

## pyenvとは
pyenvとは、複数のバージョンのPythonを切り替えて使うことが出来るツールです。

https://github.com/pyenv/pyenv

## venvとは
venvとは、複数の仮想環境を構築し、切り替えて使うことが出来るツールです。

https://docs.python.org/ja/3/library/venv.html

## 環境構築手順
### pyenvインストール
※pyenvのGitHubに記載の手順に沿ってインストールします。

※環境変数の設定については以下を参照。
https://github.com/pyenv/pyenv

※依存関係パッケージは以下を参照。
https://github.com/pyenv/pyenv/wiki#suggested-build-environment

```
# Gitインストール
yum install git

# インストーラ実行
curl -fsSL https://pyenv.run | bash

# 環境変数の設定
# ~/.bashrcに設定する場合は以下の通り
echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
echo '[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(pyenv init - bash)"' >> ~/.bashrc

# シェルの再読み込み
source ~/.bashrc

# 依存関係パッケージのインストール
yum install gcc make patch zlib-devel bzip2 bzip2-devel readline-devel sqlite sqlite-devel openssl11-devel tk-devel libffi-devel xz-devel
```

### Pythonインストール（pyenv）
```
# インストール可能なバージョンの確認
pyenv install -l

# Pythonインストール
pyenv install 3.10.18

# Pythonインストール（Prefix使用）
pyenv install 3.10
```

### Pythonのバージョン切替（pyenv）
```
# 現在のシェルのセッション内でのPythonバージョンを指定する
pyenv shell 3.10.18

# ユーザーアカウント全体でのPythonバージョンを指定する
pyenv global 3.10.18 

# ユーザーアカウント全体でのPythonバージョンを指定する（Prefix使用）
pyenv global 3.10
```

### Python仮想環境の作成（venv）
```
# venvで仮想環境を作成する
python -m venv /path/to/new/virtual/environment

# 例）ユーザのホームディレクトリ配下に作成する例
python -m venv ~/venvs/ansible_216
```

### Python仮想環境の有効化・無効化（venv）
```
# 仮想環境を有効化する
source /path/to/new/virtual/environment

# 仮想環境を無効化する
deactivate
```
PostgreSQL コミュニティの英知から学ぼう

## 最初から、本題です

PostgreSQL 文書（＝公式マニュアル）は、すばらしい文書ですよね。でも、本格的に PostgreSQL を使い始めたり、認定試験に備えようとすると、さまざまな追加の情報源に頼ると思います。そうした情報源は書籍やブログ、wiki、商用の製品/サービスの公開ナレッジベースや FAQ など、多岐にわたります。そうしたコミュニティの人々の英知には助けられることが少なくないでしょう。

しかし、散財した情報源から望む情報をなかなか見つけられないこともあると思います。また、トラブルシュートではなく、学習のために、マニュアルでは得にくい、得られない知識を、できれば効率的に獲得できたらと思うこともあるでしょう。

そこで、PostgreSQL コミュニティの wiki に
[Operations cheat sheet](https://wiki.postgresql.org/wiki/Operations_cheat_sheet)
を作成しましたので、ご活用ください。これは、ネット上の多様な情報源から、私が独断でコミュニティのみなさんの英知を選んで、その要点を凝縮したものです。各章の最後の節 References には、本文の情報源を列挙していますので、そこからみなさんの英知をじっくり味わうこともお勧めします。

といっても、実は、これは 2024 年 1 月に PostgreSQL コミュニティが運営するブログ集約サービスである [Planet PostgreSQL](https://planet.postgresql.org/) を通じて公開したものです。今回、この Qiita Tech Festa のテーマに合うと思い、より多くの日本の方々にも知っていただこうと紹介しました。

このページは、
[PostgreSQL Wiki のトップページ](https://wiki.postgresql.org/)
から、「General articles and guides」 → 「Operations cheat sheet」というリンクでたどり着けます。

みなさんも、コミュニティの英知を見つけて、「これを埋もれさせるのはもったいない！」と思ったら、ぜひ、この wiki ページに追加してください。なお、この wiki サイトの記事を編集するには、
[PostgreSQL Wiki のトップページ](https://wiki.postgresql.org/)
にあるように、PostgreSQL コミュニティ・アカウントを作り、コミュニティのメーリングリストに対して編集権限を要求する必要があります。

最後に、私はこうしたコミュニテぃの実践的な知恵は、PostgreSQL 文書（＝マニュアル）に蓄積していくのがよいと考えます。内容は厳選され、形式もだいぶ異なるものになるとは思いますが。どうでしょう、コメントでご意見をうかがえるとうれしいです。公式文書に英知が集まり、AI が回答でそれを参照すれば、AI の回答も信じやすくなりますよね。みなさんの声と、私の余力があれば、開発コミュニティに文書のパッチを投稿していくかもしれません（ただ、ほかにやるべきこと、やりたいことが多いので、余裕が・・・）。


## もうおわりです: 余談なので読まなくてだいじょうぶです

これを作ろうと思ったきっかけは、PostgreSQL について教える機会があったことです。どうやって実践的な知識を効率よく得てもらおうかと考えてました。

一方、Planet PostgreSQL には日々、コミュニティの人々が現場で経験した「生きた知恵」が流れてくるが、流れていってしまい、もったいないと思っていました。

そこで、独断による選択とはなってしまいますが、コミュニティの英知を貯めて、見てもらえたらと考えました。Planet PostgreSQL には 300 ～ 400 ものブログサイトが登録されていて、それらサイトにも複数の記事があるため、それらをすべて読むのはとても大変でした・・・。

公開してまもなく、
[Hacker News](https://news.ycombinator.com/item?id=39042456)
で取り上げてくださったのは意外で、うれしかったです。この記事の中で、私の wiki 記事の書式が崩れているというコメントがありますが、それは今は修正済みです。私は視覚障害のために画面が見えないので、見た目のことには気づきにくいのです。この Qiita 記事もだいじょうぶかしら。